Фу, переобулся
Я вам рассказывал, что уже несколько месяцев на новом проекте работаю. Это группа проектов с ежедневной аудиторией больше 1млн человек.
Тут я обычный senior разработчик, и не могу так влиять на процессы, как обычно
И, короче, тут Redux)
Думаю, вы знаете моё отношение к редаксу...
И, знаете, мне зашло 😄
Дело в том, что он оправдан.
1. Здесь есть сложная клиентская бизнес логика маркетингового толка (Показ всевозможных баннеров на всякие условия). Это жутко сложная штука.
2. Сложные анимации, которые должны быть связаны с бизнес flow (Пока анимация не завершится, не можем продолжить)
3. Есть потребность в управлении загрузкой приложения ещё до того, как загрузился React чанк
4. Очень сложный флоу инициализации приложения. Который ещё нужно оптимизировать для улучшения tti
И здесь должны были сиять redux + redux-saga, как инструменты созданные именно для этого. Для описания сложной клиентской бизнес логики.
Но использовались они совершенно не верно...
Вместо того, чтобы описывать полноценные бизнесовые флоу, redux саги использовались как фитчилки данных. А вся логика была размазана по десяткам useEffect
Каждый раз, когда нужно было сделать редирект, поток данных нырял из саг в useEffect и обратно🤢
Короче, всё смешалось. redux бездарно использовался как react-query, а useEffect использовался повсеместно при живой redux-saga
Сначала я выпал в осадок от очередного разочарования от редакса. Но сразу понял, что не Redux виноват.
redux-saga – единственный актуальный инструмент, который здесь идеально подходит.
Но вообще нигде нет информации, как правильно использовать Redux Redux-saga rtk
Осознав это, я расчехлил все свои знания об архитектуре и наработки по выпиливанию логики из useEffect. Ну и, конечно, всё своё влияние)
И вот что получилось:
1. Приложение теперь redux-first. То есть сначала инициализируется redux, и потом уже init-saga управляет сложным процессом инициализации (минус 20 useEffect)
2. Добавил управление роутером через экшоны. Благодаря этому получилось не выпрыгивать из саг для описания flow (минус сотни useEffect)
3. Внедрил react-query для запросов, и выкинул кэш сервера из redux. В редакс остались только бизнес данные. Интегрировал через redux-saga (Минус тысячи строк кода)
4. Разделил понятия команд и событий, что позволило однозначно разделить логику между редьюссерами и сагами.
5. Описал всё это в целостной архитектуре, с чёткими ролями и обязанностями
И в результате получилось охеренно.
Не представляю, на каком инструменте можно было бы сделать такие сложные вещи понятными и предсказуемыми.
Но точно не на useEffect🤮
Я вам рассказывал, что уже несколько месяцев на новом проекте работаю. Это группа проектов с ежедневной аудиторией больше 1млн человек.
Тут я обычный senior разработчик, и не могу так влиять на процессы, как обычно
И, короче, тут Redux)
Думаю, вы знаете моё отношение к редаксу...
И, знаете, мне зашло 😄
Дело в том, что он оправдан.
1. Здесь есть сложная клиентская бизнес логика маркетингового толка (Показ всевозможных баннеров на всякие условия). Это жутко сложная штука.
2. Сложные анимации, которые должны быть связаны с бизнес flow (Пока анимация не завершится, не можем продолжить)
3. Есть потребность в управлении загрузкой приложения ещё до того, как загрузился React чанк
4. Очень сложный флоу инициализации приложения. Который ещё нужно оптимизировать для улучшения tti
И здесь должны были сиять redux + redux-saga, как инструменты созданные именно для этого. Для описания сложной клиентской бизнес логики.
Но использовались они совершенно не верно...
Вместо того, чтобы описывать полноценные бизнесовые флоу, redux саги использовались как фитчилки данных. А вся логика была размазана по десяткам useEffect
Каждый раз, когда нужно было сделать редирект, поток данных нырял из саг в useEffect и обратно
Короче, всё смешалось. redux бездарно использовался как react-query, а useEffect использовался повсеместно при живой redux-saga
Сначала я выпал в осадок от очередного разочарования от редакса. Но сразу понял, что не Redux виноват.
redux-saga – единственный актуальный инструмент, который здесь идеально подходит.
Но вообще нигде нет информации, как правильно использовать Redux Redux-saga rtk
Осознав это, я расчехлил все свои знания об архитектуре и наработки по выпиливанию логики из useEffect. Ну и, конечно, всё своё влияние)
И вот что получилось:
1. Приложение теперь redux-first. То есть сначала инициализируется redux, и потом уже init-saga управляет сложным процессом инициализации (минус 20 useEffect)
2. Добавил управление роутером через экшоны. Благодаря этому получилось не выпрыгивать из саг для описания flow (минус сотни useEffect)
3. Внедрил react-query для запросов, и выкинул кэш сервера из redux. В редакс остались только бизнес данные. Интегрировал через redux-saga (Минус тысячи строк кода)
4. Разделил понятия команд и событий, что позволило однозначно разделить логику между редьюссерами и сагами.
5. Описал всё это в целостной архитектуре, с чёткими ролями и обязанностями
И в результате получилось охеренно.
Не представляю, на каком инструменте можно было бы сделать такие сложные вещи понятными и предсказуемыми.
Но точно не на useEffect