Когда мы пишем программное обеспечение, одна из самых больших проблем заключается в том, как мы должны обращаться с состоянием? У пользователя есть форма для заполнения и обновления полей. Должны ли данные, то есть состояние, сохраняться в объекте или управляться библиотекой, чтобы у нас был легкий доступ к ним и в других местах? Или состояние должно просто отражаться в DOM со значением полей ввода?

Когда данные отправляются на сервер, как мы обрабатываем постоянство? Должны ли мы использовать реляционную базу данных или какую-то новую и причудливую базу данных NoSQL? И что более важно: как мы справляемся с его мутацией от нескольких пользователей?

С помощью некоторых фреймворков мы получили ответы на многие из этих вопросов, и мы можем двигаться дальше. Бэкенд-фреймворки, такие как Rails, Django или Laravel, решают за нас множество проблем с базами данных. Как мы можем решить управление состоянием во внешнем интерфейсе?

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

Что я имею в виду под локальным состоянием и глобальным состоянием?

Различие довольно простое: глобальное состояние — это данные, которые могут отображаться в разных областях пользовательского интерфейса. Иногда эти данные могут быть обновлены через различные формы. И чаще всего некоторые компоненты пользовательского интерфейса отображают некоторые значки / значки или другие вещи в соответствии с определенным состоянием. Хорошим примером этого является значок получено новое сообщение в Facebook, LinkedIn или других веб-приложениях. Как правило, все, что мы получаем с сервера, следует рассматривать как глобальное состояние.

С другой стороны, локальное состояние — это данные, которые представляют, как отображается пользовательский интерфейс, или данные, которые являются изменчивыми, т. е. не сохраняются. Например. для компонента вложенного модального диалога это флаг, если диалог открыт. Или это может быть логика, которая решает, видны ли некоторые поля формы. Обычно это состояние каким-то образом зависит от глобального состояния и может быть просто производным от него.

Должны ли мы проводить различие между этими двумя типами государства?

В некоторых архитектурах, например в Архитектуре вязов (TEA), каждое состояние является глобальным. Это прекрасно работает, если разработчик убедился, что структура данных, представляющая состояние, эффективна. Лично я нахожу JavaScript немного запутанным, но Elm позволяет легко настроить тип, который представляет все, что вам нужно, не теряясь в деталях.

Почему бы нам не обрабатывать состояние внутри наших компонентов?

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

Если данные настолько важны, что мы сохраняем их, мы, вероятно, захотим использовать их во многих компонентах. Когда мы делаем это, мы создаем тесную связь между этими компонентами, а чтобы разделить их, мы создаем глобальное хранилище данных, доступ к которому есть у всех.¹ Таким образом, мы создаем интерфейс, от которого зависят эти компоненты. на, вместо фактической реализации. Ember.js управляет состоянием таким образом, и это прекрасно работает.

У нас есть два варианта, куда поместить данные, чтобы сделать их доступными. Мы можем использовать контекст React или библиотеку управления состоянием, такую ​​как Recoil или Redux.

Когда мы должны использовать контекст для состояния?

Большое преимущество Context состоит в том, что он включен в React из коробки. Документация великолепна, концепция довольно проста для понимания, а с API достаточно легко работать. Но, вариант использования ограничен! Контекст следует использовать, когда он содержит данные, которые не меняются или, по крайней мере, меняются не часто. Почему это так? Потому что, когда данные изменяются внутри контекста all, дочерние элементы будут перерисовываться независимо от того, зависит ли компонент от данных. Итак, если мы используем контекст для данных, которые сильно меняются, мы создаем узкое место в производительности.

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

Для всех остальных данных следует рассмотреть возможность использования библиотеки управления состоянием.

Варианты управления состоянием в React

Библиотеки управления состоянием имеют долгую историю в React. Redux, например, был выпущен в 2015 году, всего через два года после выпуска самого React. Redux был вдохновлен TEA.

Совсем недавно Recoil тоже удалось набрать обороты. Recoil очень хорошо интегрируется с React, поскольку он также разработан на основе Facebook и использует современные функции React, такие как Hooks.

С этими библиотеками, конечно, можно использовать и локальное состояние. Мы можем просто использовать хук useState в наших компонентах.

Заключение

Государственное управление всегда было трудным. Но с помощью таких библиотек, как Recoil, и немного дальновидности с нашей стороны, это становится проще. Теперь у нас есть все возможности для создания веб-приложений с хорошей архитектурой, полагаясь на проверенные инструменты, которые нам не нужно изобретать самостоятельно.

¹ Хранилище, которое обрабатывает данные, должно быть импортировано, чтобы фактически использовать его. Это работает как доступ к контексту или другому компоненту.

P.S. Во-первых, вы должны получать мои сообщения в свой почтовый ящик. Вы можете сделать это здесь! Во-вторых, если вам нравится работать с Medium, подумайте о том, чтобы поддержать меня и тысячи других авторов, подписавшись на членство. Это стоит всего 5 долларов в месяц, и у вас также есть возможность зарабатывать деньги своим письмом. Зарегистрировавшись по этой ссылке, вы поддержите меня напрямую частью своего гонорара, это не будет стоить вам больше. Если вы это сделаете, спасибо вам миллион раз!

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Присоединяйтесь к нашему сообществу Discord.