Итак, в последние несколько месяцев в сообществе Javascript происходит много шума по поводу React и Redux. Все пишут свое приложение на React.
В Crowdfire у нас был новый продукт, и у нас был тот же вопрос, какой фреймворк выбрать и который лучше всего подходит для наших нужд.
Поэтому мы решили перечислить требования и проверить, какая философия решит проблемы.
Нет призов за то, чтобы угадать, с каким из них мы пошли. Мы выбрали React + Redux. Вместо того, чтобы слепо следовать фреймворку, мы решили разобраться в концепции, чтобы это помогло нам понять, что происходит под капотом.
Лучший способ понять фреймворк - это воссоздать его базовую концепцию самостоятельно. Вот что мы сделали.
Я собираюсь говорить здесь только о концепциях Redux. Давайте углубимся в детали.
Три ключевых принципа Redux:
- Единый источник истины
Состояние всего вашего приложения хранится в дереве объектов в едином хранилище . - Состояние доступно только для чтения
Единственный способ изменить состояние - вызвать действие, объект, описывающий, что произошло. - Изменения вносятся с помощью чистых функций
Чтобы указать, как дерево состояний преобразуется действиями, вы пишете чистые редукторы.
Подробности вы можете прочитать в Официальной документации Redux.
Как мы его восстановили:
Мы переписали основные понятия на чистом JS.
1. Создан магазин, в котором будет храниться состояние нашего приложения.
Вот так выглядел наш магазин. this.state инициализируется начальным состоянием.
2. Создал диспетчерский метод
Это единственный способ изменить состояние приложения. Диспетчер вызывается вместе с типом действия, который указывает, как должно быть изменено состояние.
3. Создана функция, которая изменяет состояние на основе действия.
Этому методу передается свойство action.type, а для запуска изменения состояния на основе action.type используется случай переключения.
4. Создан метод подписки на изменение состояния
Этот метод используется, когда приложению необходимо прослушивать изменения, происходящие с состоянием.
Теперь у нас есть базовые концепции Redux.
Теперь мы можем использовать любую логику рендеринга для создания пользовательского интерфейса на основе состояния приложения, и если какие-либо действия пользователя должны изменить состояние, оно должно пройти через диспетчер.
Что мы узнали
Теперь у нас есть четкое представление о том, как redux работает внутри, что помогает нам легко отлаживать проблемы и намного лучше прогнозировать наше приложение.
Спасибо за прочтение. Если вам понравилась эта статья, нажмите Рекомендовать или напишите ответ ниже. Вы можете связаться со мной в Twitter @narendra_shetty.
