Загрузка реакт != рендер реакт

Ну так в чем проблема внутри реакта вызвать show?

аааааааааааааааааааааааааааааааааааааа

просто хочу показать для наглядности как это бьет по глазам можно сказать код из доки...

а есть предположение что это за белое окно? это окно в которое в эту мс загрузится renderer или иное?

а есть предположение что это за белое окно? это окно в которое в эту мс загрузится renderer или иное?

Это анимация системы?

проблемы не вижу, даже без хаков "после рендера"

nuxt у меня отсутствует, какой либо SSR тоже. ПРохрачное окно на 50-100 мс вопрос к X Server а не к электрону

если возможно мог бы кто-то глянуть? https://github.com/WebAFilippov/af-electron где - https://github.com/WebAFilippov/af-electron/blob/main/src/main/libs/create-window.ts -> создаю окно где - https://github.com/WebAFilippov/af-electron/blob/main/src/main/index.ts -> инициализирую окно

Не думаю что effect выполняется после применения dom

Next это делает до открытия браузера

вроде победил(очень сильно надеюсь) установил transparent: true,

а можешь ради интереса попробовать такое? const observer = new MutationObserver(() => { observer.disconnect() setTimeout(() => { // call show window }, 0) }) observer .observe(document.querySelector('#app'), { childList: true }) ?

Т.е до монтирования прилы этот кусок Так надежнее

в общем это первый шаг реакта ниже

так же белое окно?

это именно с холодного старта?

в целом да. реакт еще не завелся

electron-window-state случайно не используешь?

прост он почему то сам открывает окна до какого либо show

Возможно, кто-то уже сталкивался с подобной задачей. Я хочу проксировать трафик рендерера (через defaultSession) через локальную прокси-сервис внутри приложения. Цель — использовать одну точку выхода трафика из приложения, чтобы можно было модифицировать его или добавить промежуточную прокси (upstream proxy). То есть, трафик сначала проходит через мою прокси, где его можно либо изменить, либо пропустить без изменений, а затем он отправляется дальше или на следующую прокси. Этот подход работает отлично с решениями, которые генерируют полноценные сертификаты и осуществляют настоящий MITM (Man-in-the-Middle) с использованием CA-сертификата. В Electron я обычно добавляю обработчик ошибки сертификата, который либо игнорирует ее, либо выполняет валидацию, сопоставляя сертификат прокси с тем, который указан в запросе. Однако этот метод кажется чересчур громоздким и избыточным. Есть ли более простой способ перехвата трафика до его шифрования? Используя ограниченные возможности API webRequest в Electron (документация), через этот API можно только отменить запрос, сделать редирект или модифицировать заголовки. Этого явно недостаточно для моей задачи.

Всем привет, подскажите как лучше сделать: Есть приложения с возможностью запуска нескольких задач одновременно, работает из консоли, вся логика написана на golang Я хочу сделать GUI реализацию по типу как на фото, но оставить логику на golang Насколько правильно вызывать под каждый ивент запуска child process голанга с аргументами? Какая вообще лучшая практика в таких приложениях?

Да знаю про wails, меня в целом интересует как устроены такие приложения и коммуникация между ними. Вариант с вызовом процесса через command line arguments адекватный? Если приложение дочернее будет выдавать логи в консоль я смогу их вынести на фронт?

Да знаю про wails, меня в целом интересует как устроены такие приложения и коммуникация между ними. Вариант с вызовом процесса через command line arguments адекватный? Если приложение дочернее будет выдавать логи в консоль я смогу их вынести на фронт?

И насколько быстрый такой вариант? Условно если у меня 50 процессов сразу запускается можно оставить так или лучше зашить в ноду логику

Всем привет, подскажите как лучше сделать: Есть приложения с возможностью запуска нескольких задач одновременно, работает из консоли, вся логика написана на golang Я хочу сделать GUI реализацию по типу как на фото, но оставить логику на golang Насколько правильно вызывать под каждый ивент запуска child process голанга с аргументами? Какая вообще лучшая практика в таких приложениях?

если каждая программа это отдельный процесс то к каждому spawn но если возможно на го объедини все в 1 процесс и уже в зависимости от команд обращаться к нужной std.write

Приложение которое на го хранит условно 10 функций, это же лучше чем дробить его на 1 приложение - 1 функция? Я планирую просто вызывать процесс с аргументами и параметрами, и код на го будет сам понимать, что ему делать

Или ты имеешь в виду в качестве каждого таска не использовать новый процесс, а реализовать все в рамках одного?

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