Основы Redux (теория)
Last updated
Last updated
ОБНОВЛЕНИЕ 2018: Вышло второе издание (современный код и версии пакетов, данное издание УСТАРЕЛО)
На канале так же проводятся бесплатные вебинары, публикуются переводы и авторские материалы, присоединяйтесь!
Курс рассчитан на создание приложения по шагам, а это значит максимум практики и минимум теории. Тот самый минимум, перед вами.
Давайте еще раз взглянем на схему нашего приложения:
В шапке слева заголовок и три кнопки выбора года. Ниже - фото соответствующего года, отсортированное по количеству лайков.
В шапке справа - ссылка войти/выйти.
Представим, как должны выглядеть данные для такой страницы:
Поздравляю вас, мы только что описали как должно выглядеть состояние (state) нашего приложения.
За содержание всего состояния нашего приложения, отвечает объект Store. Как уже не раз упоминалось - это обычный объект. Важно, что в отличии от Flux, в Redux только один объект Store.
Не хочется оставлять вас надолго без практики, поэтому процесс создания store и немного подробностей про него я аккуратно вплету в следующие главы, а пока достаточно того, что: store, "объединяет" редьюсер (reducer) и действия (actions), а так же имеет несколько чрезвычайно полезных методов, например:
getState()
- позволяет получить состояние приложения;
dispatch(actions)
- позволяет обновлять состояния, путем вызова действия;
subcribe(listener)
- регистрирует слушателей
Actions описывают действия.
Actions - это простой объект. Обязательное поле - type. Так же, если следовать соглашению, все данные, которые передаются вместе с действием, кладут внутрь свойства payload. Таким образом, для нашего приложения, мы можем составить, например такую пару actions:
Чтобы вызвать actions, мы должны написать функцию, которая в рамках Flux/Redux называется - ActionsCreator (создатель действия), но перед этим стоит принять во внимание, что обычно тип действия, описывают как константу. Например, константы вашего проекта:
Возникает вопрос, зачем? В маленьких проектах - незачем. В больших - это удобно. Пока, просто запомните.
Вернемся, к ActionsCreator, один из наших "создателей действий", выглядел бы так:
Итого: actions сообщает нашему приложению - "Эй, что-то произошло! И я знаю, что именно!"
"Actions описывает факт, что что-то произошло, но не указывает, как состояние приложения должно измениться в ответ, это работа для Reducer'а" - (офф. документация)
Наше приложение не нуждается в нескольких редьюсерах, но крайне необходимо познакомить читателя с reducer composition, так как это фундаментальный шаблон построения redux приложений: мы разбиваем наше глобальное состояние на кусочки, за каждый кусочек отвечает свой reducer. Кусочки объединяются в Корневом Редьюсере (rootReducer).
Так как у нас есть reducer'ы page
и user
, можно представить следующий диалог:
А на js выглядело бы так:
Обратите внимание, мы не мутировали наш state, мы создали новый state. Это важно. Крайне важно. В редьюсере, мы всегда должны возвращать новый объект, а не измененный предыдущий.
На практике, я буду использовать object spread syntax, поэтому предыдущую функцию с Object.assign можно переписать следующим образом:
Объект, который мы возвращаем в редьюсере, далее с помощью функции connect
, превратится в свойства для компонентов. Таким образом, если продолжить пример с фото, то можно написать такой псевдо-код:
Благодаря этому, внутри компонента <Page />
, мы сможем получить фото, как this.props.photo
Я постарался очень кратко дать самую важную теорию.
Если что-то осталось не понятным, не переживайте, на практике мы все закрепим и тогда все встанет на свои места.
Схематично, наше приложение можно представить так: