ThunderCat

Никак
При клике запрос делается браузером пользователя и значит скрыть ничего не получится
И скрывать эти данные не имеет смысла. Если не хотите чтобы пользователь видел какие-то данные - не отдавайте ему их никогда.

ни на сколько: в озвученном виде - вопрос вообще абсолютно дебильный: для себя я пишу на последней, для работодателя я пишу на той, которая ему нужна. даже если это четверка (хотя есть несколько экстравагантов даже с тройкой).
хотя контекст вопроса может повлиять на ответ.

0. Берете откуда-то данные
1. Передаете их в URL.createObjectURL в нем и происходит вся магия - создается специальный объект, который браузер может "скачать".
2. Затем берете какую-то ссылку (или создаете новую), в ее href записываете этот url из предыдущего пункта
3. Делаете по ссылке .click() - и вызывается диалог сохранения файла.
4. Дело сделано, ссылку можно удалить, память можно очистить (revokeObjectURL)

Вот пример без внешних зависимостей:


Если у вас файл скачивается, но он то пустой, то ошибка при открытии - причина где-то в пункте 0, там где вы получаете или формируете pdf. И этот код вы не показываете.
Чтобы в этом удостоверится, смените тип на text/plain и в блоб передайте строку типа "hello world".
Попробуйте передать готовую PDF-ку, которая точно не пустая и нормально открывается.

Да просто если печатать страничку из браузера, всю красоту легко может перекосоебить вплоть до нечитаемости самых важных циферок.
А PDF гарантирует - что задумывал разработчик, то и будет на печати.

принято ли в срезе разработки веб приложений СНГ писать коммиты на русском?

У нас как только не пишут. Бывает, что мешают по несколько языков в одном проекте, в том числе и в компаниях, которые себя позиционируют как очень модные. Все зависит от конкретных людей в конкретном месте.

Но чем более подкованные специалисты в команде, тем больше вероятность, что они между собой договорятся все унифицировать и писать коммиты по конкретной схеме (это больше не про язык в вакууме, а про последовательность в проекте, чтобы было проще ориентироваться). Очень вероятно, что при этом выберут английский, т.к. скорее всего "русские" сообщения коммитов будут состоять из:

1. Англицизмов, которые еще и не имеют однозначной транслитерации в кириллицу, что ломает поиск по коммитам.
   
2. Названий классов, файлов, или еще каких-то сущностей из мира кода, которые и так уже переведены и есть в исходниках проекта на английском.
   
3. Набора базовых глаголов, которые ставят в начале предложений, вроде "добавил", "исправил", "удалил".
   

Тут как бы получается выбор между очень ограниченным техническим английским и рунглишем, а не между чистым литературным английским и чистым и грамотным русским языком.

если его присылают на клиент?

Его присылают НЕ на клиент, а на определённый урл, который наверняка указывается в настройках при подключении платёжки.



За 2 минуты нашёл инструкцию на их сайте. Как вы гуглите?

Для того чтобы правильно писать catch, надо писать осмысленный код.

А здесь мы наблюдаем очаровательный пример карго-культа.
Узнав, что "толстый контроллер - это плохо, а сервисы - это хорошо", автор небрежным движением руки замел весь мусор под ковёр перенёс весь код из контроллера в "сервис". Ну а что? Контроллер худой, весь код в сервисе!
Тот факт, что сама кривая структура проекта осталась, по сути, той же самой, нас не смущает.
Как и то, что сервис вдруг начал выполнять функции НТТР контроллера и кидать почему-то НТТР исключения. Что с этими исключениями делать в случае, если тот же сервис будет вызван из консольной команды - загадка.

Но самое забавное, что при всём при этом контроллер всё равно пытается выполнять работу модели. Казалось бы, какое отношение интерфейс для обслуживания НТТР запросов имеет к транзакциям в базе данных? А вот поди ж ты!

Чтобы сделать этот код осмысленным, контроллеру всё-таки придется потрудиться, и выполнить какую-то работу самому, а не перекладывать на "сервис". А так же отдать модели то что ей принадлежит.

В общем транзакцию перекинуть в createDefault. причём не напрямую, а ещё ниже - в слой для работы с БД. Стартовать транзакцию до валидации данных - это как бы *не совсем логично*, мягко говоря. И в итоге, как по волшебству, весь этот говнокод исчезнет как страшный сон.
При этом в параметрах передавать не НТТР реквест чохом, а осмысленный набор параметров, вынутый предварительно из реквеста!
В частности, если модель сама проверяет права доступа, то и передавать ид пользователя из авторизации.

При этом модель не должна кидать НТТР исключения. Она должна кидать исключения бизнес-логики. Которые контроллер уже может ловить и транслировать в хттп. Но тут видимо уже сложнее, поскольку это ж ларавель судя по всему.

В любом случае, уж catch (Exception $e)-у тут точно не место

Но это если рассматривать твой конкретный случай.
В общем же случае правильный код написал Илья.

То есть внутри трая операции с БД и коммит.
в кетче роллбэк и перевыброс исключения. Только ловить надо Throwable

try {
  DB::beginTransaction();
  // запись в БД
  // запись в БД
  // запись в БД
  DB::commit();
} catch (\Throwable $e) {
  DB::rollBack();
  throw $e;
}

Ты хочешь написать квери билдер. Практически всё уже написал.
Всего-то надо вместо значений подставлять плейсхолдеры, а сами значения запоминать в переменной.
Общий принцип такой:

class Test {
    protected $where;
    protected $params;

    public function getAll()
    {
        $result=$this->db->prepare("SELECT * FROM table WHERE 1=1 ".$this->where);
        $result->execute($this->params);
        return $result->fetchAll(PDO::FETCH_ASSOC);
    }

    public function byDate($start,$end=false)
    {
        if ($end) {
            $this->where .= " AND data BETWEEN :start AND :end";
            $this->params['end'] = $end;
        } else {
            $this->where .= " date >= :start";
        }
        $this->params['start'] = $start;
        return $this;
    }

    public function byCol($col)
    {
        $this->where .= " AND col = :col";
        $this->params['col'] = $col;
        return $this;
    }
}

$sql = new Test;
$data = $sql->byCol($col)->byDate($start)->getAll();

по-хорошему тут еще должны быть отдельные переменные для самого запроса, для order by, limit и так далее
Но начать можно с такого

с помощью этой штуки https://www.electronjs.org/docs/tutorial/quick-start
можно поискать видосы на ютубе по ней

У бесперебойников в общем-то две основные характеристики - максимальная мощность и емкость батареи. Мощность - ее прямо в названии в магазинах пишут. Ее должно хватать для типичного потребления компьютера. Для описанных в вопросе пк скорее всего и 300 Вт будет всегда хватать. Можно брать любой самый дешевый. А батарея - тут зависит от необходимого времени работы автономной. Почти любого ИБП хватит, чтобы нормально выключить компьютер. А если надо прямо проработать какое-то время, то гуглим "nix время автономной работы ИБП при нагрузке" и получаем список из протестированных ибп вместе с ценами.

const container = document.querySelector('селектор контейнера с select\'ами');
const selectSelector = 'селектор select\'ов';
const input = document.querySelector('селектор input\'а');
const updateInput = selects => input.value = Array.from(selects, n => n.value).join(' ');

container.addEventListener('change', function() {
  updateInput(this.querySelectorAll(selectSelector));
});

// или

const selects = container.querySelectorAll(selectSelector);
const onChange = updateInput.bind(null, selects);
selects.forEach(n => n.addEventListener('change', onChange));