Defront — про фронтенд-разработку и не только
19.9K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Кент Си Доддс опубликовал у себя в блоге статью про то, как управлять состоянием приложения, не используя сторонние библиотеки, "Application State Management with React".

Кент в статье критикует Redux и пишет про то, что с использованием хука useState и Context можно организовать полноценное управление состоянием приложения в удобном виде и показывает это на примерах. Описанный подход можно реализовать с использованием обычных компонентов, но результат будет не так красив как с хуками. Разработчики React в последних версиях библиотеки благословили использование Context в обычных приложениях (а не только в библиотеках для управления состоянием), поэтому его можно использовать не опасаясь, что с обновлением React в вашем приложении что-то может сломаться.

Напоследок поделюсь своими мыслями. В React теперь есть механизм управления состоянием. Означает ли это, что разработчики будут трансформировать библиотеку в полноценный фреймворк? Наверное нет, так как React всегда позиционировался как гибкое решение. Добавление механизма хуков упростило работу со стейтом, и благодаря этому хук useReducer был добавлен в React как органичное дополнение (моё имхо, конечно).

#react #statemanagement #musings

https://kentcdodds.com/blog/application-state-management-with-react
Посмотрел доклад Джефа Ши из Netflix про то, как развивалась их часть React-приложения, отвечающая за регистрацию нового пользователя — "Redux For Transactional Apps".

Из доклада мне запомнилось то, как они боролись с разобщённостью флоу процесса регистрации на разных платформах: Web, Mobile, TV. На каждой платформе транзакции описывались в самом приложении (в докладе под транзакцией подразумевается пошаговое изменение состояния приложения). Логика транзакций в итоге была перемещена в API, что позволило решить проблему.

Ещё в докладе Джеф рассказал про то, какой профит они получили при использовании Redux. Благодаря тому, что view отделено от стейта, они могут использовать одну и ту же логику изменения состояния на разных платформах, просто подменяя компоненты, отвечающие за представление.

Доклад не хардкорный. Не могу сказать, что он будет полезен всем. Но если вы работаете с React, то посмотреть его можно.

#react #statemanagement #talk

https://youtu.be/V8oTJ8OZ5S0?t=1134
Нашёл интересную статью Яна Моншке из Soundcloud про оптимизацию потребления памяти в Redux-приложении — "Garbage Collection in Redux Applications".

При портировании Soundcloud на Xbox One разработчики столкнулись с тем, что операционная система закрывала работающее в фоне приложение, когда потребляемая память превышала 128Мб. Проблема оказалась в Redux-сторе — данные треков, которые уже были не нужны, продолжали лежать в памяти.

Для решения проблемы удаления устаревших данных разработчики реализовали подобие алгоритма сборки мусора mark-and-sweep. В их случае фаза "mark" работает с помощью кастомного коннектора стора, который отслеживает данные, которые нужны для отображения примонтированных компонентов. Фаза "sweep" реализована как обычный редюсер, который начинает работать при получении экшена, который сигнализирует о запросе начать повторное формирование стора на основе информации собранных на этапе "mark". В конце процесса получается новый стор, в котором лежат только актуальные объекты.

Рекомендую посмотреть статью, если столкнулись с проблемой потребления памяти в Redux-приложении.

#statemanagement #performance #react

https://developers.soundcloud.com/blog/garbage-collection-in-redux-applications?ref=mdbootstrap.com
Марк Эриксон рассказал о том, в каких случаях Redux не самое лучшее решение — "When (and when not) to reach for Redux".

Redux появился в 2015 году и был очень популярен несколько лет, но сейчас это не самый лучший инструмент. Вопрос кэширования данных взяли на себя библиотеки swr, React Query, Apollo. Проблемы с явной передачей пропсов от корня к дочерним компонентам (props drilling) решается в React из коробки, начиная с версии 16.3, благодаря стабилизировавшемуся Context API. Также Марк говорит о том, что Redux неоптимален для работы со стейтом, но не приводит альтернатив, поэтому позволю себе наглость добавить их от себя: Mobx, Reatom, Effector.

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

#react #statemanagement

https://changelog.com/posts/when-and-when-not-to-reach-for-redux
Марк Эриксон — майнтейнер Redux — написал статью с подробным объяснением, почему Context в React не может заменить стейт-менеджеры — "Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)".

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

Хорошая статья. Рекомендую почитать, если работаете с React.

#react #statemanagement

https://blog.isquaredsoftware.com/2021/01/context-redux-differences/