Основными составляющими любого приложения являются его пользовательский интерфейс и состояние приложения. Неприкосновенность и предсказуемость состояния приложения имеют первостепенное значение для любого приложения. Чтобы упростить эту задачу, у нас есть библиотеки управления состоянием. В этой статье я расскажу о необходимости управления состоянием, а также расскажу, как работает redux.

Потребность в государственном управлении

Обычно у нас есть пользовательский интерфейс, и состояние обычно распределяется по приложению. В приложении на основе реакции состояние распределяется по компонентам и по самой DOM.

Это разрозненное состояние создает множество проблем, когда более чем одному компоненту требуется доступ к одному и тому же фрагменту состояния. Обычно мы перемещаем состояние в родительский компонент и передаем его в качестве свойств компоненту, который в нем нуждается. Что, если компонент, которому он нужен, находится на 6–7 уровней ниже родительского компонента. Эта практика, хотя и не неправильная, довольно громоздка и утомительна. Если все наше состояние находится в дереве состояний Redux, нам не нужно обо всем этом беспокоиться, компонент, которому это нужно, может получить его напрямую из дерева состояний.

Итак, вместо того, чтобы распределять состояние по приложению, что, если бы у нас оно было в одном месте. Это то, что мы называем деревом состояний.

Взаимодействие с деревом состояний и понимание того, как работает Redux

Теперь, когда мы поняли суть и необходимость существования дерева состояний, давайте углубимся и поймем, как redux облегчает обработку дерева состояний и состояния приложения в целом.

Для создания библиотеки государственного управления это building-blocks.

  • Сначала нам нужно все наше состояние в одном месте.
  • Затем нам нужно «ПОЛУЧИТЬ» состояние из дерева состояний.
  • "СЛУШАЙТЕ" изменения в состоянии
  • «ОБНОВИТЬ» дерево состояний

Все это вместе составляет наш Магазин.

Создание магазина и взаимодействие с ним

На основе 4 building-blocks, упомянутых выше, давайте создадим нашу createStore() функцию

function createStore(){
// Create the state tree
// GET the state tree - getState()
// LISTEN for changes - subscribe()
// UPDATE the state tree - dispatch()
}

Каждый раз, когда вызывается функция createStore(), пользователи будут иметь доступ к методам getState() subscribe() и dispatch().

Инициализация state и getState функции

В нашей функции createStore() мы инициализируем состояние, а также функцию getState(), задача которой просто вернуть текущее состояние. Также getState() возвращается из основной функции, так что он доступен как метод при вызове createStore.

const myStore = createStore();
myStore.getState()// returns the current state 

Прослушивание изменений с помощью подписки

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

Пользователь вызывает subscribe и передает функцию, которая помещается в массив наблюдателей. Чтобы отказаться от подписки, мы возвращаем функцию обратного вызова, которая является не чем иным, как вспомогательной функцией массива фильтров, проверяющей, существует ли уже переданная функция в массиве наблюдателей. Затем он возвращает массив, содержащий все остальные функции, кроме переданной ему.

Обновите дерево состояний

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

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

Поскольку это объект, мы можем добавить любую дополнительную информацию, которая нам нужна, которая поможет нам изменить состояние хранилища в зависимости от вызываемого типа. Это называется ACTION - это объект, который представляет событие, которое изменяется. состояние нашего магазина

Теперь, когда у нас есть состояние и действия, нам нужно как-то связать их вместе. Действия должны иметь свойство типа, чтобы указать «тип» выполняемого действия. Помимо «типа», структура действия довольно гибкая.

Функции редуктора

Функции-редукторы должны быть чистыми функциями, которые принимают текущее состояние и действия и возвращают обновленную версию состояния, не изменяя ее.

Редукторы наблюдают за отправкой type действий и затем обновляют состояние. Если вы заметили, что в приведенном выше коде мы используем .concat() вместо .push, чтобы существующее состояние не изменялось.

Отправьте действия

После того, как редукторы определены, все, что нам нужно, - это иметь возможность «отправить» действие, чтобы редукторы получали свои инструкции о том, что и что более важно, как изменять состояние.

Обратите внимание, что createStore() теперь принимает в качестве параметра редуктор, так что внутри dispatch() мы можем динамически обращаться к редукторам и передавать действия для получения текущего состояния. Когда у нас есть состояние, мы вызываем все функции в нашем массиве наблюдателей.

Это наша полностью функционирующая Библиотека государственного управления.

Заключение

В этой статье я попытался дать представление о том, как работает redux. Лучшее понимание внутренней работы может дать гораздо более ясную картину того, где и как их использовать. Также я подчеркнул тот факт, что неприкосновенность состояния имеет первостепенное значение, и как redux помогает нам поддерживать его, особенно в больших приложениях.