Вы находитесь на странице: 1из 4

Чистая функция

Функция должна удовлетворять двум условиям, чтобы считаться «чистой»:

— Каждый раз функция возвращает одинаковый результат, когда она вызывается с тем же
набором аргументов

— Нет побочных эффектов

Примеры побочных эффектов:

1. Видоизменение входных параметров


2. console.log
3. HTTP вызовы (AJAX/fetch)
4. Изменение в файловой системе
5. Запросы DOM

Три принципа
Redux может быть описан тремя фундаментальными принципами:

Единственный источник правды


Состояние всего вашего приложения сохранено в дереве объектов внутри
одного стора.

console.log(store.getState())

{
visibilityFilter: 'SHOW_ALL',
todos: [
{
text: 'Consider using Redux',
completed: true,
},
{
text: 'Keep all state in a single tree',
completed: false
}
]
}
Состояние только для чтения
Единственный способ изменить состояние — это применить экшен —
объект, который описывает, что случится.
Это гарантирует, что представления или функции, реагирующие на события сети
(network callbacks), никогда не изменят состояние напрямую. 
store.dispatch({
type: 'COMPLETE_TODO',
index: 1
})

store.dispatch({
type: 'SET_VISIBILITY_FILTER',
filter: 'SHOW_COMPLETED'
})

Мутации написаны, как чистые функции


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

Редюсеры — это просто чистые функции, которые берут предыдущее состояние


и экшен и возвращают новое состояние. 

Асинхронные экшены (Async Actions)

Для каждого из этих моментов обычно может требоваться изменение состояния


приложения (application state). Для изменения состояния вы должны запустить
(dispatch) нормальные экшены, которые будут обработаны редюсером
синхронно. Обычно для любого API запроса вам понадобится запустить
(dispatch) по крайней мере три разных вида экшенов?

 Экшен, информирующий редюсер о том, что запрос начался.

Редюсер может обрабатывать такой вид экшена, переключая флаг isFetching в


состоянии приложения. Именно так UI понимает, что самое время показать
лоадер/спиннер.
 Экшен, информирующий редюсер о том, что запрос успешно
завершился.
Редюсер может обрабатывать такой вид экшена, объединяя полученные из
запроса данные с состоянием, которым управляет этот редюсер и сбрасывая
флаг isFetching.
 Экшен, информирующий редюсер о том, что запрос завершился
неудачей.

Редюсер может обрабатывать такой вид экшенов, сбрасывая флаг isFetching.


Также некоторые редюсеры могут захотеть сохранить сообщение об ошибке,
чтобы UI мог его отобразить.

Асинхронные генераторы экшенов


Наконец, как мы используем синхронные генераторы экшенов, созданные нами
ранее вместе с сетевыми запросами? Стандартный для Redux путь — это
использование Redux Thunk middleware . Этот мидлвар (middleware) содержится
в отдельном пакете, который называется redux-thunk. Мы поясним, как работают
мидлвары позже. Сейчас есть одна важная вещь, о которой вам нужно знать:
при использовании конкретно этого мидлвара, генератор экшенов может
вернуть функцию, вместо объекта экшена. Таким образом, генератор экшена
превращается в преобразователь (Thunk)
Когда генератор экшена вернет функцию, эта функция будет вызвана
мидлваром Redux Thunk. Этой функции не обязательно быть чистой. Таким
образом, в ней разрешается инициировать побочные эффекты (side effects), в
том числе и асинхронные вызовы API. Также эти функции могут вызывать
экшены, такие же синхронные экшены, которые мы отправляли ранее.

Thunk middleware — это не единственный путь управления асинхронными


экшенами в Redux.

 Вы можете использовать redux-promise или redux-promise-middleware  для


отправки Promises вместо функций.
 Вы можете использовать redux-observable для отправки Observables
 Вы можете использовать мидлварь redux-saga для создания более
комплексных асинхронных экшенов
 Вы можете использовать мидлварь redux-pack для отправки асинхронных
экшенов, базирующихся на промисах
 Вы даже можете писать собственные мидлвары, для описания вызовов
вашего API, как например в real world example .

Асинхронный поток
Без мидлвара (middleware) Redux стор поддерживает только синхронный поток
данных. Это то, что вы получаете по умолчанию с createStore().
Асинхронный мидлвар, типа redux-thunk или redux-promise, оборачивает метод
стора dispatch() и позволяет вам вызывать что-то, что не является экшеном,
например, функции или Промисы. Любые мидлвары, которые вы используете, могут
интерпретировать все, что вы вызываете, и, в свою очередь, могут передать экшены
следующему мидлвару в цепочке. Например, мидлвар промисов (Promise middleware)
может перехватывать промисы и отправлять пару начало/конец экшенов асинхронно в
ответ на каждый промис.

Mидлвар (Middleware)
Они предоставляют стороннюю точку расширения, между отправкой экшена и
моментом, когда этот экшен достигает редюсера. Люди используют Redux-
мидлвары для логирования, сообщения об ошибках, общения с асинхронным API,
роутинга и т.д.

Middleware - ф-ция, которая принимает store, возвращает ф-цию которая


принимает dispatch, которая возвращает ф-цию которая принимает action.

В redux есть функция applyMiddleware(), которую мы


должны передать параметром в функцию Createstore
И в данном функции мы перечисляем набор мидлваеров
которые мы хотим использовать в проекте.
С помощью redux-thunk мы можем диспачить
ассинхронные экшены.
Import reduxThunk from ‘redux-thunk’;
const store = (rootReducer, applyMiddleware(reduxThunk));