Приятных выходных!

Можно ожидать появления инстанциируемых моделей в effector. Основная цель — добавление API для создания инстансов моделей для динамичских списков. Получится, например, сделать классный менеджер форм с динамическими полями, а также обобщить написание кода.

API может выглядеть вот так:

const counterModel = model({
  props: {},
  create() {
    const $counter = createStore(0)
    const incremented = createEvent()

    $counter.on(incremented, (counter) => counter + 1)
    return { $counter, incremented }
  }
})

const counter = spawn(counterModel)

sample({
  clock: incrementClicked,
  target: counter.props.incremented,
})

Я думаю, это API должно решить проблему усложнения проекта, когда существующий код внезапно нужно вызывать для элементов списка. Сейчас нужно переписывать на keyval или ему подобные решения, чтобы избежать создания моделей в рантайме.

API model/spawn будет решать этот кейс через создание шаблона модели, а уже затем при отправке в неё ивентов определять в какой именно инстанс прилетит апдейт. В общем, идея простая, но в частности вылезает очень много нестандартных кейсов.

Я всё еще буду продолжать настаивать на том, что создавать инстансы моделей в компонентах — плохая идея. А пока что динамика может быть таким escape hatch для SPA-only приложений.

Публичное обсуждение можно посмотреть в треде:
https://www.tg-me.com/effector_ru/337809

А внутренний документ с некоторыми деталями API:
https://effector.notion.site/Effector-models-5cca5c90410c4707ab1cdaea37e0cbae

Начнем неделю с резюме разработчика!
Ищите в свою команду frontend-разработчика с образованием магистра машинного обучения и высоконагруженных систем?

Danila Anisimov – разработчик с опытом в создании веб-приложений и AI-решений на React и Next.js.
Крайне рекомендую почитать резюме, возможно именно этот разработчик отлично подойдет вашей команде.

Контакты: https://linkedin.com/in/danila-anisimov | https://github.com/ExLineP

🚦Роутинг

Или как мы топчемся на месте.

Современная веб разработка приучила нас к тому, что "роут" - компонент на какому-то пути.
Все популярные решения (react-router, Next.js, Angular, Vue и пр.), каждый со своими фичами сбоку, обыгрывают именно этот концепт.
Если попробовать дать им общее определение, то будет что-то вроде "Роутинг - механизм связи URL, данных и интерфейса".

Достаточно ли этого?
Действительно ли роутинг в вебе это просто {path, element, loader, …}?
Для начала попробую сформулировать общее определение.

Роутинг в клиентских приложениях - механизм управления переходами между узлами пользовательских сценариев, состоянием этих узлов и их связью с внешним миром.

Покрывают ли это мейнстримные решения?
Безусловно, но настолько изолировано, ограничено и с привязкой к конкретному окружению, что мы не можем связать роутинг с остальной логикой без костылей, а всё, что не заложено в решение (а заложено только `.push("/another/path”)`), будет физически невозможно и придется реализовывать это самим.

Что такое роут?

Роутом, или, как я сформулировал выше, "узлом" может быть любой самодостаточный элемент пользовательского пути, например:
- Любая страница/лейаут
- Виджет выбора эмоджи
- Диалоговое окно
- Полноэкранный поиск (популярный нынче `⌘K`)
- Окно с выбором стикеров в телеграме в виде тултипа, открываемого при наведении

В приложенном коде я наметил возможную реализацию последнего примера, тултипа со стикерами в телеграме, на effector и atomic-router.

В тот момент, когда логика "что-то открылось/закрылось" перестает быть неважной деталью реализации и становится явным звеном пользовательского сценария, это "что-то" становится роутом.

Неважно открыт тултип или нет, это просто подсказка в интерфейсе, но, когда в нём целый виджет, "неважная деталь реализации" становится ключевой, у виджета появляется роут и логика работы с ним.
И не имеет значения что это - тултип, страница или модалка, это просто способ связи роута и внешнего мира.

Внешний мир

То, что мы привыкли считать неотъемлемыми частями роутинга, - лишь частные случаи.
В мобильных приложениях и виджетах нет URL.
В тестах не нужны компоненты.
В коде большинства продуктов нет голых путей, все работают через какую-то абстракцию по типу .push(routes.product.edit({ id: ... })), ведь строки - неудобный и откровенно дырявый способ идентификации роутов.
Люди делают приложения, роутинг которых почти полностью построен на модалках.

В логике нет путей, в логике нет компонентов, всё это - внешний мир.

Расширяемость

В приложенных схемах я попробовал отразить разницу мейнстримных моделей и общей модели, выведу основные тезисы.

Ограниченная модель:
- Прибита к компонентам и к URL/файлам
- Нет явных сущностей роутов, вся работа через строки
- Любая "фича" - частный случай, а не системное решение (react-router тут явно лидирует)
- Реализует под капотом самопальную реактивную систему

Расширяемая модель:
- Строится поверх общей реактивной системы
- Дает базовые примитивы - явные сущности роутов и основные методы для построения логики
- Все "фичи" и сайд-эффекты (URL / компоненты / ...) реализуются поверх базовых примитивов
- Логика роутинга напрямую связана со всей остальной логикой

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

Мораль

А нет её, в мейнстриме всё плохо, второй десяток лет с завидным упорством запрягаем старую клячу, надеюсь, мы всё же увидим прогресс.
А пока можете попробовать atomic-router.

Уже через час будет круглый стол по архитектуре на Podlodka React Crew.

https://www.tg-me.com/sergeysova/955

Увидимся там!

Если вы присутствовали на круглом столе, напишите свой отзыв, пожалуйста.

Ну и здесь можно продолжить дискуссию, написать свои вопросы/комментарии/мнение.

А ещё, если есть желание увидеться со спикерами.
Я в ближайшее время в Армении.

А вот и запись!

https://youtu.be/7p7dJTyz4i4

P.S.
Если вы хотите, чтобы мне было не пофиг на дизлайки, то пишите в комментах, почему их ставите. Критику готов послушать.

Вместо Next.js я использую vike.dev для SSR проектов.

Один из громадных плюсов это глубокая кастомизация (при необходимости), а также удобства для разработчика.

Столкнулся с проблемой: при клиентских переходах не запускается логика effector. При перезагрузке страницы, а именно запуске логики на сервере, всё ОК, но на клиенте при navigate(), пустота. Лишь в логах видно getPageContextFromHooks.

Пошел смотреть в репу:
https://github.com/vikejs/vike/blob/main/vike/client/client-routing-runwww.tg-me.com/getPageContextFromHooks.ts

А там куча комментов от разработчиков. В итоге, за пару минут чтения, а потом и исправления всё пофиксил.
Оказалось, что запуск логики нужно размещать в +onBeforeRender.ts, а не в +onRenderHtml.tsx.

Документация пока что не покрывает вопросы глубокой интеграции с СТМ. Хотя комментарии во внутреннем коде многое объясняют, за что спасибо разработчикам.

Как еще можно использовать patronum

Продолжаем разбираться зачем использовать patronum, если можно всё описать через combine().

Такие шортхенды как and, or, not, и т.д. позволяют сократить количество кода и повысить наглядность.

Для начала разберемся, что за кусочек логики тут описан, sample описывает один шаг в сценарии:
clock: когда что-то случилось,
source: взять данные отсюда,
filter: если выполняется условие,
target: передать сюда данные из source.

Когда пользователь нажал Продолжить,
Взять email и OTP,
Если email И OTP валидны
И этап логина НЕ initial,
Начать верификацию OTP.

Без шортхендов фильтр выглядел бы так:

combine(
  $emailValid,
  $otpValid,
  $stageInitial,
  (email, otp, stageInitial) =>
   email && otp && !stageInitial
),

Год назад я писал о том, что запускаю образовательную программу "Разработка по-взрослому". Ее цель — погрузить участников в разработку фронтенд-приложений, рассказать, зачем таким проектам нужна архитектура, как проще использовать React, в каких случаях полезен Effector и т.д.

Изначально в программе рассказывалось, как разработать приложение, но сами по себе знания в формате видео не дают практических навыков. Хоть рассказываемые практики остаются проверенными и работающими, в ряде случаев оказалось сложно донести их в видеоформате. Поэтому мы меняем формат: участники будут писать свой продукт, а мы выступим в роли менторов.

Помимо этого, мы улучшили формат программы: продолжительность видео уменьшили до 30 минут, переехали из Telegram на веб-платформу для более удобного просмотра материалов, дополнили видео статьями, а также добавили тесты для самопроверки.

Этот пост – начало открытого рассказа о нашем опыте создания образовательной программы на основе готового проекта. Наша задача в этой программе — научить писать и запускать веб-приложения в продакшен, используя лучшие практики, планирования разработки, деплоя в продакшен с резервными копиями и отслеживанием метрик.

#react #typescript #architecture #effector

В комментариях я напишу еще детали…

Мне нравится, что декларативный подход effector не так сильно раздувает API, которое необходимо, чтобы писать приложения практически любой сложности.

P.S.
Справедливости ради, сюда вполне можно докинуть patronum, atomic-router, farfetched, effector-*, и это всё будет раздувать необходимое для работы API.

Насколько мне известно, такая же ситуация обстоит и с другими стейт-менеджерами, поэтому приводить её не стал.
Решить проблему конечно можно, так как образовалась пачка устойчивых регулярных пакетов, можно сделать мета-пакет типа npm install framework-react, внутрь которого засунуть все необходимые обычно пакеты.

SpaceX приводнили свой огромный корабль.

За 4 запуска им удалось достичь настолько амбициозной цели.
Я все это к чему, мы наглядно видим, как огромный проект разрабатывается итеративно.

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

Если вам нужны Server Actions в vike.dev или другом серверном фреймворке, то рекомендую обратить внимание на telefunc.com

Конечно, не стоит прям писать запросы к бд в экшенах на SQL.
Есть более очевидный кейс, когда серверные экшены идеально подходят — обращение к внешним сервисам по API.

Если мы не хотим, чтобы в бандл попадал API Key, и чтобы этот ключ отображался во вкладке Network, то есть пользователь его вообще не мог увидеть.

Telefunc позволяет превратить обращение к файлу .telefunc.ts в fetch() запрос в клиентском бандле.
При этом, если писать на typescript, типы описывающие функцию будут автоматически превращены в рантайм валидацию, то есть устранена дырища серверных экшенов в next.js

Проект от создателя vike.dev, то есть вы можете рассчитывать на хороший API и расширяемость. Автор при этом довольно активно рассматривает новые варианты использования, просто посмотрите issues (закрытые тоже).

А вот в issue по ссылке ниже, вы можете увидеть как я использую vike с effector (ну немного), а также подписаться на обновления.
https://github.com/brillout/telefunc/issues/109

Если вы пользуетесь Godaddy, лучше мигрировать настолько быстро насколько возможно

Доброе утро.
Через час начнется GitHub Galaxy!

Я присутствовать не смогу, хотя очень хотел. Буду стримить про effector
https://galaxy.github.com/

Мы готовы начинать.
Вы готовы подключаться?

История получила продолжение

Ещё через 18 версий наконец-то все поймут, чем JSX был лучше всех птичьих синтаксисов.

https://dev.to/oler/introduction-to-let-in-angular-18-cm6