Что нужно знать перед использованием библиотек React, таких как Redux
Если вы читаете это, вы, вероятно, задаетесь вопросом, нужна ли вашему приложению или веб-сайту сторонняя библиотека для управления состоянием — или, может быть, вы думаете, что она вообще не нужна.
Здесь я объясню, когда это может быть полезно, а когда бесполезно для вашего приложения.
State in React: возможные проблемы
Если вы разработчик React, возможно, вы не знаете, что State — это не конкретная концепция React, а общая концепция JavaScript.
Это основная концепция, поскольку она отслеживает состояние нашего приложения и описывает его с течением времени.
В частности, React состоит из нескольких компонентов, каждый из которых может иметь состояние, а с введением хуков мы можем использовать состояние и внутри функциональных компонентов.
Независимо от того, используем ли мы функциональные или классовые компоненты, при работе с React мы передаем данные от родителей к дочерним через пропсы.
Иногда эти данные должны быть разделены между множеством дочерних элементов в приложении, а иногда и очень отдаленными внутри дерева компонентов.
С ростом нашего приложения это может стать первой проблемой для производительности и качества кода.
Если мы хотим разделить состояние между большим количеством дочерних элементов, нам нужно сохранить его в компоненте более высокого уровня.
Однако, делая это, особенно если наша структура сложнее, чем приложение списка дел, мы можем столкнуться со второй проблемой.
Все мы знаем, что компоненты React автоматически повторно рендерятся, если происходит повторный рендеринг родительского компонента или обновление их свойств или состояния. перерендерить тоже, даже если они не используют состояние.
Если в браузере Chrome установлены инструменты для разработки и реагирования, вы можете легко проверить это, включив параметр «Выделять обновления при отображении компонентов».
Конечно, повторный рендеринг не означает реального обновления объектов в DOM.
Это связано с тем, что React использует Virtual DOM, виртуальное представление DOM.
Каждый раз, когда состояние нашего приложения изменяется, виртуальный DOM обновляется вместо реального DOM. Каждый раз, когда объект в Virtual DOM изменяется, React обновляет только эти объекты в реальном DOM.
Взгляните на замечательную статью Кента С. Доддса.
ContextAPI: оно того стоит?
Иногда мы думаем, что решением может быть использование ContextAPI, чтобы избежать передачи реквизитов через промежуточные элементы.
Короче говоря, мы используем Provider для передачи значений в дерево ниже, и любой компонент может их прочитать.
Компоненты-потребители, называемые Consumer, которые являются потомками этого Provider, могут подписываться на эти изменения контекста.
Все потребители будут перерисовываться всякий раз, когда изменяется свойство значения Provider.
Контекст предоставляет способ передачи данных через дерево компонентов без необходимости вручную передавать реквизиты на каждом уровне.
(Источник: https://it.reactjs.org/docs/context.html)
С таким решением мы можем разделить состояние между дочерними элементами, но остается вторая проблема, потому что, если значения внутри контекста изменяются, все компоненты все равно будут перерисовываться.
Из-за этого ContextAPI может быть полезен только в нескольких ситуациях, например, при смене предпочтительной темы, языка и настроек, поскольку изменение их значений происходит не очень часто.
В общем, это хорошее решение проблемы проп-сверления, когда данные передаются от компонента более высокого уровня к компоненту более низкого уровня, и мы хотим избежать передачи реквизита на каждый уровень дерева. .
Таким образом, мы можем использовать его для решения первой проблемы разделения состояния между дочерними элементами, но нам нужно что-то еще, чтобы предотвратить повторный рендеринг.
Возможное решение: сторонняя библиотека
Решением для этого является использование сторонней библиотеки для управления состоянием для улучшения качества кода и производительности.
Есть много интересных библиотек, чтобы делиться состоянием наших компонентов во всем приложении и хранить его в магазине, например, Recoil или Redux.
Использование такого рода библиотек позволяет нам обмениваться данными между всеми компонентами и в то же время сохранять код простым и предотвращать повторный рендеринг.
Таким образом, будут повторно рендериться только те компоненты, которым нужно это значение. и они тоже могут изменить состояние.
Редукс
Одна из самых известных библиотек, которая может помочь нам лучше обрабатывать сложную и вложенную логику состояний, — это Redux, библиотека для управления и обновления состояний приложения с использованием единого хранилища для их хранения.
Все глобальное состояние вашего приложения хранится в дереве объектов внутри одного хранилища. Единственный способ изменить дерево состояний — создать действие, объект, описывающий произошедшее, и отправить его в хранилище. Чтобы указать, как состояние обновляется в ответ на действие, вы пишете чистые функции reducer, которые вычисляют новое состояние на основе старого состояния и действия.
Источник:https://redux.js.org/
Я не буду объяснять, как работает Redux, потому что здесь есть много руководств, но я хочу только подчеркнуть улучшение, которое произошло с появлением Redux Toolkit.
Первоначально созданный для сокращения стандартного кода «классического» Redux и упрощения настройки хранилища, это стандартный способ написания логики Redux.
Попробовав его с Toolkit и без него, я увидел, насколько просто стало реализовать его в коде, особенно с введением функции createSlice.
Я думаю, что Redux Toolkit — очень устоявшаяся и мощная библиотека, но даже после этого код остается немного шаблонным, особенно для новичка.
Но есть еще одна библиотека, в которой все просто и минимально.
Отдача
Recoil — это очень молодая библиотека с открытым исходным кодом, созданная инженером-программистом Facebook для решения именно нашей проблемы с управлением состоянием.
Она предоставляет глобальное состояние, такое как Redux, поэтому мы можем поделиться им со всеми компонентами нашего приложения, но минимально. и лаконично по сравнению с другими библиотеками, которые заставят вас полюбить ее.
Еще одна ключевая особенность заключается в том, что он помогает вам сохранять код очень простым, без дополнительной логики, сокращая кривую обучения для новых пользователей.
Это также идеальный выбор для уже существующих проектов.
Короче говоря, он использует единицы состояния, называемые атомами, на которые могут подписываться компоненты. Они могут обновляться и подписываться, и когда атом обновляется, каждый подписанный компонент повторно отображается с новым значением.
Кроме того, он предоставляет полезную функцию под названием Селектор, используемую для замены состояния производными данными без изменения используемых компонентов.
Атом представляет часть состояния. Атомы могут быть прочитаны и записаны из любого компонента. Компоненты, которые считывают значение атома, неявно подписаны на этот атом, поэтому любые обновления атома приведут к повторному рендерингу всех компонентов, подписанных на этот атом.
Источник: https://recoiljs.org/
Я не буду писать подробный гайд по Recoil, а только хочу отметить простоту реализации и использования.
На самом деле разделяемое состояние имеет такой же простой интерфейс получения/установки, как и локальное состояние React.
Чтение и запись этих маленьких единиц очень просты и непосредственны, как хук useState.
Кроме того, функции атомов очень минимальны, и мы можем создать их даже с помощью нескольких строк кода.
Таким образом, вы можете начать использовать Recoil там, где вам это нужно, написав всего несколько строк кода.
Как использовать его в своем приложении: мое мнение
Простота принятия Recoil или огромная популярность Redux также могут быть тривиальным выбором для разработчиков, у которых может возникнуть соблазн использовать и злоупотреблять внешней библиотекой управления состоянием в каждом состоянии приложения.
Когда дело доходит до использования такой библиотеки, ее действительно легко использовать для решения всех проблем без каких-либо усилий, но мы должны быть осторожны, потому что производительность приложения может быть снижена из-за злоупотребления этими инструментами.
Лучше использовать там, где нам нужно разделить состояние между многими компонентами или в очень вложенных. В большинстве случаев, когда нам нужно передать его очень немногим дочерним элементам, лучше сохранить состояние в общем предке.
Заключение
Время для краткого обзора, чтобы подвести итоги. Когда дело доходит до использования внешней библиотеки для совместного использования состояния в приложении, нам необходимо учитывать несколько важных моментов:
- Если вы хотите поделиться глобальными состояниями только для всех компонентов, таких как темы или настройки, ContextAPI может быть хорошим решением, поскольку эти значения не меняются очень часто.
- Как я уже говорил, если ваши компоненты очень часто перерендериваются, это не обязательно плохо сказывается на производительности.
- Если некоторые компоненты перерисовываются слишком часто и вы видите снижение производительности, или вам сложно обмениваться состояниями между очень вложенными дочерними элементами, возможно, вам следует рассмотреть возможность использования этих библиотек для упрощения кода или повышения производительности. Поэтому, пожалуйста, внимательно подумайте, действительно ли вам нужно решить эту проблему с помощью добавления контекста или внешней библиотеки.
- Если вам нужно использовать его, не забывайте использовать его экономно и старайтесь не решать все свои проблемы таким образом, потому что могут быть более эффективные решения.
Таким образом, в общем, в зависимости от вашего приложения и проблемы, с которой вы столкнулись, если вам нужна помощь, сторонняя библиотека может быть использована для решения некоторых проблем, которые в противном случае могли бы усложнить вашу жизнь.
Надеюсь, вам понравится моя статья. Спасибо за прочтение.
