Ребята, хуки в React — код намертво прибитый к View.

Я даже не представляю, с чего люди взяли, что завернув свой код в хук, код сразу же становится вынесенным из компонента. Это вообще не так!

А как понять, когда код отделен от View или же прибит намертво?
Легко, попробуйте запустить его без React, за пределами компонента. Да так, чтобы семантика поведения сохранилась и все работало как раньше. Всякие хаки с моком useState, useEffect не в счет, потому что здесь как раз мокаются методы React, то есть код зависим от View.

К тому, же, хуки жить не могут без react lifecycle. Да даже банально посмотрите, какие методы хуки юзают внутри себя — конечно же это методы React. Так как вообще можно назвать код, который использует методы React, называть отвязанным от View? Если эти же хуки используются ТОЛЬКО внутри React-компонентов?

Но, в чем проблема, скажут некоторые?
А в том, что код прибитый к React, невозможно переиспользовать в любом другом месте. А также любые данные, которые лежат в React Context невозможно использовать за пределами React-компонента. А раз хуки невозможно использовать где-то еще, то и логика в них оказывается зашита и код придется дублировать.

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

Код асинхронных преобразований уже написан и вызывается на 5-6 уровней вложенности выше формы. Там создается контекст, в который прокинута куча методов для работы с формой. После сабмита формы, запускается валидация, как на сервере, так и на клиенте, затем запрашиваются дополнительные данные, а уже потом нужно преобразовать данные формы в реальный чек с финансовыми операциями, а затем отправить на бекенд.

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

И я в тупике. Код ПРИДЕТСЯ продублировать для чека в форме и для формирования чека при отправке формы. А к чему это ведет? Да к десяткам багов, потому что используется react-hook-form, который не может гарантировать правильных типов для полей формы, к тому же спокойно проставляет undefined как начальное значение для любого поля формы.

Если я изменю расчет чека в клиенте, то спокойно могу забыть изменить его в другой функции, в совершенно другом месте приложения. Я не могу объединить код в единую функцию, потому что тогда аргументов становится более чем 2 десятка.

Как решить проблему?
Полностью удалить все возможную бизнес-логику из хуков. В хуках рассчитываем только всякие UI-штуки, вроде анимаций, отслеживания opened у dropdown и прочее тому подобное. Компонент по сути должен только оповещать нашу бизнес-логику о том, что что-то произошло, например “кнопка отправки нажата”, “изменился получатель платежа”, “изменилась валюта”, “страница смонтирована” и так далее. И именно бизнес-логика реагирует на эти события так, как ей нужно, она может начать грузить данные, взять их из кеша, вообще ничего не делать. Компоненту должно быть все равно, он просто рендерит данные, которые ему подсовывает бизнес-логика.

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

Очень рекомендую посмотреть видео от создателя XState на эту тему. Автор доклада рассказывает о том, почему всякая логика внутри useEffect приводит к проблемам.

https://youtu.be/HPoC-k7Rxwo

Завтра вечером будем разбираться что такое полином и полиномиальная сложность!

Я не шарю в этой теме, но кто понимает как оно устроено и что значат эти слова, пожалуйста присоединяйтесь. Мы поспрашиваем и разберемся вместе!
На канале будет live call!

Кому интересна эта тема ставьте лукас 👍

Начинаем когда соберется побольше человек.

Личные консультации по effector, react и FSD!

За почти 10 лет коммерческого опыта в веб-разработке, я насобирал внушительный опыт в разных технологиях. Хотя специализируюсь я в React + Effector, готов помочь решить очень разнообразные задачи и ответить на массу вопросов.

Чем конкретно я могу помочь за выделенный час-два:
• Объясню как решить задачу на effector, настроить связанный с ним тулинг и написать тесты.
• Помогу отдебажить приложение, найти узкое горлышко в коде, проработать элементы приложения с архитектурной точки зрения.
• Проведу быстрое ревью архитектуры React-приложения, помогу понять узкие места, обозначу migration plan и расскажу почему-зачем нужно проводить такие изменения.

• Помогу в проектировании библиотечного кода, DX и типизации на TypeScript.
• Проанализирую бизнес-кейс в продукте и помогу разобраться как лучше реализовывать его в указанных условиях.
• Помогу с выбором технологического стека на старте проекта, учитывая требования бизнеса, существующую команду, возможности расширения и особенности продукта.
• Настрою процесс взаимодействия с командой Backend и проектирования API, а также помогу проработать конкретно ваше API.

На самом деле это не исчерпывающий список, я готов выслушать любой ваш кейс, касающийся Frontend, DevOps, CI/CD, процессов в команде, найме и обучении.

Писать @sovasergey, репост очень приветствуется.

Effector Halley 22.2.0

Еще в начале февраля я снял видео-обзор новых фич effector 22.2.0. Но все сильно поменялось, как и планы публикации видео.

Видос готов, думаю он будет полезен. Фидбек очень жду!
https://www.youtube.com/watch?v=pTq9AbmS0FI&1

За все это время я собрал довольно много полезных инструментов и статей для frontend и rust разработчиков!

https://news.sova.dev/issues/17-1181475

Я знаю способ как обелить крипту для властей РФ.
А какие вы способы знаете?
Я свой сформулирую и напишу позже

За что я не люблю Next.js:

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

Врагу не пожелаю писать на Next.js что-нибудь серьезное

Я забыл предупредить. Я планирую немного хейтспич)
У меня всегда так с непонятными мне инструментами

В рассылке всего 4 человека открыли статью про читабельность кода.

Поэтому повторю здесь ссылку:

https://ruudvanasseldonk.com/2022/03/20/please-put-units-in-names

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

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

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

Этот адский текст фактически может описать реактивность. Но в случае с React и хуками, такую реактивность крайне больно реализовывать из-за наличия setState, useEffect, useMemo. Логика просто превращается в адскую жопу.

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

Не делайте себе и коллегам больно