А использовать подобный компонент можно например вот так.
Мне очень нравится, когда компонент и его props со значениями читаются как предложение.
#effector
Мне очень нравится, когда компонент и его props со значениями читаются как предложение.
#effector
👍32
Давайте подведем итоги 2022 года! (Спасибо, за репост)
Final Results
11%
У меня все отлично, даже лучше чем представлялось
9%
Все хорошо, цели достигнуты, минимум стресса
36%
Средне, как обычно, что-то хорошо, что-то упущено, стресса хватило
26%
Мало что доведено до конца, излишняя тревога, многие планы сорваны
18%
Ужасно, постоянный стресс, невозможно что-либо планировать, когда это закончится
🫡4🍾1
Как работает общение между процессами в Electron.
Я не хотел делать по типичным советам из гайда Electron. Они еще рекомендуют сделать специальную прослойку через файл
В
В
Одинаковые импорты важны, ведь в настройках сборки я прохожусь по файлам процессов main и renderer с помощью babel. Я просто вписал импорты выше в factories в
Теперь у каждого запроса созданного через createRequest будет свой уникальный sid. И благодаря общей конфигурации компилятора и сборщика для обеих частей electron сиды будут идентичны. Имя эффекта просто поможет его явно идентифицировать в логах отладки.
В следующем посте я покажу как использовать эти запросы в renderer и main процессах. Жмите ⚡️ если узнали что-то новое.
#effector #electron
Я не хотел делать по типичным советам из гайда Electron. Они еще рекомендуют сделать специальную прослойку через файл
preload.js
, мне было лень, но даже его можно автоматизировать по примеру, который я покажу.В
ipc/factory.ts
я создал домен и функцию создающую запросы. Создаю запросы не через домен, чтобы не было соблазна навесить обработчик сразу при создании эффекта. Плюс, так визуально можно разделить обычные эффекты и запросы.В
ipc/db.ts
я собственно описываю эти запросы, главное тут это типы и sid. Чтобы все заработало, потребовалось добавить алиасы для @ipc/db
и @ipc/factory
, это нужно, чтобы из main процесса (nodejs) и renderer (chrome) можно было импортировать эти файлы одинаково.Одинаковые импорты важны, ведь в настройках сборки я прохожусь по файлам процессов main и renderer с помощью babel. Я просто вписал импорты выше в factories в
effector/babel-plugin
. Можно было использовать swc, но мне как-то привычнее babel. Я использовал vite-plugin-electron, чтобы собирать обе части приложения.Теперь у каждого запроса созданного через createRequest будет свой уникальный sid. И благодаря общей конфигурации компилятора и сборщика для обеих частей electron сиды будут идентичны. Имя эффекта просто поможет его явно идентифицировать в логах отладки.
В следующем посте я покажу как использовать эти запросы в renderer и main процессах. Жмите ⚡️ если узнали что-то новое.
#effector #electron
⚡16👍2🔥1
Подсоединяю логику обработки запросов в electron.
Модуль
Для идентификации запросов используется как раз таки
По этой же причине, запросы лежат в отдельной директории ipc в корне проекта и туда же настроены алиасы. Путь к файлам с запросами идентичен в обеих системах сборки.
На самом деле, можно добавить рантайм валидацию данных, например с помощью runtypes. Если интересно, покажу как это сделать, жмите 💯. Но структурно ничего не поменяется, лишь появится новый код внутри
В файле
Схема обработки запроса из renderer процесса будет выглядеть как-то так:
1. renderer вызывает
2. событие попадает в
3. когда эффект завершает своё выполнение, ответ возвращается обратно renderer-процессу
Функция
#effector #electron
Модуль
ipc-requests.ts
добавляет обработчики всем запросам созданным через createRequest
. В данном случае, я слушаю сообщения по каналу ipcMain. Метод .handle
позволяет дождаться выполнения асинхронного кода и отправить результат обратно в renderer процесс.Для идентификации запросов используется как раз таки
.sid
. Если для renderer и main процесса будут разные компиляторы и системы сборки, крайне важно удостовериться, что юниты получают идентичные sid'ы.По этой же причине, запросы лежат в отдельной директории ipc в корне проекта и туда же настроены алиасы. Путь к файлам с запросами идентичен в обеих системах сборки.
На самом деле, можно добавить рантайм валидацию данных, например с помощью runtypes. Если интересно, покажу как это сделать, жмите 💯. Но структурно ничего не поменяется, лишь появится новый код внутри
.onCreateEffect
.В файле
ipc-database.ts
я добавляю хендлеры для всех запросов из @ipc/db
. Можно было бы сделать специальный TS-тип, чтобы иметь гарантии, что все запросы получили хендлеры, но я решил сделать проще, для наглядности.Схема обработки запроса из renderer процесса будет выглядеть как-то так:
1. renderer вызывает
invoke('@ipc:${fx.sid}', { params })
2. событие попадает в
ipc-requests.ts
, который вызывает соответствующий эффект3. когда эффект завершает своё выполнение, ответ возвращается обратно renderer-процессу
Функция
addHandlers
из модуля ipc-database вызывается при инициализации, я вынес её отдельно, чтобы было удобно "подсовывать" нужную ссылку на базу данных. Я хочу еще в рантайме менять соединение с SQLite базой.#effector #electron
💯10⚡1👍1🔥1
Использование запросов в renderer процессе
А теперь осталось обработать вызов эффекта внутри
Самое важное на строке 9 — вызов .invoke, который дождется ответа от процесса
Использовать эти запросы, можно ровно так же, как и любые другие.
#effector #electron
А теперь осталось обработать вызов эффекта внутри
createRequest
. Но будем это делать ровно так же через domain.onCreateEffect. Большая часть кода здесь — подготовка данных и обработка ответа. Самое важное на строке 9 — вызов .invoke, который дождется ответа от процесса
ipcMain
. Я хотел сделать более прозрачную систему ответов, поэтому заворачиваю ответ в main процессе в try/catch. Но это не обязательно.Note: If the handler in the main process throws an error, the promise returned by invoke will reject. However, the Error object in the renderer process will not be the same as the one thrown in the main process.
Использовать эти запросы, можно ровно так же, как и любые другие.
#effector #electron
🔥5
Почему я не использую Tauri или Wails для создания десктопных приложений на Web-технологиях.
У Tauri есть несколько проблем:
1. платформозависимость
Когда я беру подобные системы, я хочу, чтобы мои приложения рендерились на всех системах одинаково. Чтобы мне не нужно было тратить огромное количество времени на тестирование на всех возможных версиях браузеров.
Установил приложение и полетели, не надо заставлять юзера ставить последнюю версию браузера, потому что я хочу использовать самые новые технологии.
В общем, я не хочу страдать как с обычным вебом.
Tauri использует стандартный браузер в системе, что мгновенно убивает надежность приложения.
2. Разные языки
Фуллстек-разработчик это обычно огромнейшая редкость и чаще всего миф. Пишу так, потому что нанимал фуллстеков. А теперь представьте, мы пишем приложение, у которого одна часть на Rust, а рендерилка на TypeScript.
Это значит, что один разработчик не сможет написать качественно целую фичу, ведь в десктопных-приложениях обычно как раз суть в особенных API и взаимодействии с ОС пользователя.
Придется разделять команду на бекенд и фронтенд и получать все те же проблемы, что в обычной веб-разработке.
3. Ноль переиспользования кода
В Electron я могу вынести почти любое количество кода в общий common|shared|base модуль и использовать и там и там. Могу покрыть его тестами и гарантировать корректность его работы. Это может быть логика, которая оптимистично выполняется в рендерер процессе, а в main процессе выполняется по таймеру в фоне, или же после дополнительных проверок и перед сохранением в файловую систему.
Если же использовать Tauri, то я буду вынужден продублировать логику на двух разных языках, продублировать тесты для неё и все так же выстраивать процессы разработки как в обычном вебе.
Процессы, привычки, найм в обычном вебе не плохие, но они сложные и не лишены проблем. Electron мне позволяет поставлять качественные приложения(с точки зрения бизнес-задач) на ЛЮБЫЕ платформы при этом нанимая только JavaScript разработчиков. Код можно переиспользовать и благодаря общему языку, один разработчик может спокойно разработать фичу целиком не удлиняя релизный цикл тем, что задача будет разбита на две команды.
К сожалению, я сталкивался с тем, что Tauri тупо сырой и на разных версиях Windows отказывается запускаться. Electron гораздо взрослее и уже собрал и пофиксил большинство проблем.
А про Wails я ничего не слышал, так как не считаю Go адекватным языком для больших приложений.
Спасибо 🧡
У Tauri есть несколько проблем:
1. платформозависимость
Когда я беру подобные системы, я хочу, чтобы мои приложения рендерились на всех системах одинаково. Чтобы мне не нужно было тратить огромное количество времени на тестирование на всех возможных версиях браузеров.
Установил приложение и полетели, не надо заставлять юзера ставить последнюю версию браузера, потому что я хочу использовать самые новые технологии.
В общем, я не хочу страдать как с обычным вебом.
Tauri использует стандартный браузер в системе, что мгновенно убивает надежность приложения.
2. Разные языки
Фуллстек-разработчик это обычно огромнейшая редкость и чаще всего миф. Пишу так, потому что нанимал фуллстеков. А теперь представьте, мы пишем приложение, у которого одна часть на Rust, а рендерилка на TypeScript.
Это значит, что один разработчик не сможет написать качественно целую фичу, ведь в десктопных-приложениях обычно как раз суть в особенных API и взаимодействии с ОС пользователя.
Придется разделять команду на бекенд и фронтенд и получать все те же проблемы, что в обычной веб-разработке.
3. Ноль переиспользования кода
В Electron я могу вынести почти любое количество кода в общий common|shared|base модуль и использовать и там и там. Могу покрыть его тестами и гарантировать корректность его работы. Это может быть логика, которая оптимистично выполняется в рендерер процессе, а в main процессе выполняется по таймеру в фоне, или же после дополнительных проверок и перед сохранением в файловую систему.
Если же использовать Tauri, то я буду вынужден продублировать логику на двух разных языках, продублировать тесты для неё и все так же выстраивать процессы разработки как в обычном вебе.
Процессы, привычки, найм в обычном вебе не плохие, но они сложные и не лишены проблем. Electron мне позволяет поставлять качественные приложения(с точки зрения бизнес-задач) на ЛЮБЫЕ платформы при этом нанимая только JavaScript разработчиков. Код можно переиспользовать и благодаря общему языку, один разработчик может спокойно разработать фичу целиком не удлиняя релизный цикл тем, что задача будет разбита на две команды.
К сожалению, я сталкивался с тем, что Tauri тупо сырой и на разных версиях Windows отказывается запускаться. Electron гораздо взрослее и уже собрал и пофиксил большинство проблем.
А про Wails я ничего не слышал, так как не считаю Go адекватным языком для больших приложений.
Спасибо 🧡
👍20🤡6🌚2
Во фронтенд сообществе опять драма:
один персонаж снова написал бенчи на СТМ не имеющие отношения к реальности, а другой яростно утверждает на каждом углу, что сообщество effector токсичное не участвуя в нем)
Всем доброго вечера. Заканчиваю работу над исходниками для видео об effector Encke ☄️
один персонаж снова написал бенчи на СТМ не имеющие отношения к реальности, а другой яростно утверждает на каждом углу, что сообщество effector токсичное не участвуя в нем)
Всем доброго вечера. Заканчиваю работу над исходниками для видео об effector Encke ☄️
😁19😐4🙏3🤡3💩2
Оказывается, если в npm есть пакет например
"packagename"
, то при попытке опубликовать "package-name"
, npm отбросит с ошибкой 403Package name too similar to existing package packagename; try renaming your package to '@username/package-name' and publishing with 'npm publish --access=public' instead
🤯8😁4
Forwarded from я что-то �� и всё ����
Who will win:
Modern computer, doing billions of operations per second on each core, SIMD accelerated
VS
One «O(n²) is not a problem» developer
Modern computer, doing billions of operations per second on each core, SIMD accelerated
VS
One «O(n²) is not a problem» developer
😁23🫡5🌭2
Хранить токены в localStorage и тому подобное это как хранить деньги в почтовом ящике.
Не делайте так. Статья подробно рассказывает, зачем хранить токены, куда их класть и как работают заголовки.
https://www.smashingmagazine.com/2023/01/authentication-websites-banking-analogy/
Не делайте так. Статья подробно рассказывает, зачем хранить токены, куда их класть и как работают заголовки.
https://www.smashingmagazine.com/2023/01/authentication-websites-banking-analogy/
👍26⚡4💩2👎1
Media is too big
VIEW IN TELEGRAM
Сейчас узнал, что можно иметь разные обои для рабочих столов
🥱15🤯7😁4🔥1
Forwarded from 0xLDev
💩45🤣9😁2🆒2✍1
Написал внезапно очень хороший текст для первого видео по курсу эффектора.
Для меня душ это какое-то магическое место, я постоянно придумываю какие-то хорошие тексты или роадмапы проектов, решаю сложные задачи просто стоя под горячей водой. Я хз как это работает, но похоже я изолирую свой мозг от любой внешней информации и он вынужден себя как-то развлекать, начинает решать задачи, которые давно лежат в памяти.
Что вы ждете от бесплатного курса по effector?
Можете описать в комментариях свои пожелания?
Для меня душ это какое-то магическое место, я постоянно придумываю какие-то хорошие тексты или роадмапы проектов, решаю сложные задачи просто стоя под горячей водой. Я хз как это работает, но похоже я изолирую свой мозг от любой внешней информации и он вынужден себя как-то развлекать, начинает решать задачи, которые давно лежат в памяти.
Что вы ждете от бесплатного курса по effector?
Можете описать в комментариях свои пожелания?
👏38👍8❤6🤮3🍾3