В студии HolyJS началась пожарная тревога 🔥

UPD.: уже все норм 💚

Может вы видели, в JIRA и не только таким образом можно задать estimate у задачи.

Кто-нибудь видел готовый код для парсинга этой строки и превращения в продолжительность(число)?

Речь идёт о feature-sliced.design и atomic design

И вот все эти utils, helpers без четкой структуры такое же «разное» или «мусорка».
Чтобы код был в чистоте, нужно к нему относиться соответствующе. Иначе получите ровно то, что заслужили

Отсылаю к статье: https://sova.dev/ru/why-utils-and-helpers-is-a-dump/

Новеньким добро пожаловать!
И у меня сходу вопрос: для добавления одной env-переменной, мне пришлось изменить 18 файлов.

Это норм, как считаете?

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

В новом выпуске подкаста я рассказываю о тех подходах, которые сам использую. Но все сводится к тому, что я неправильно использовал время.

https://podcast.ru/e/6gAEnGruJRS

Выкладываю выпуск подкаста как есть.

Раз уж с популярными платформами возникают проблемы(

Ребята, хуки в 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!

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