для чего нужен redux saga
Зачем использовать Redux Saga?
Вы когда-нибудь задумывались, почему redux saga приобрела такую популярность и постепенно становится сердцем любого корпоративного приложения. В этой статье я расскажу вам о преимуществах использования redux saga. Кроме того, эта статья предназначена для новичков, чтобы понять / решить, когда и зачем использовать redux saga.
Redux Saga как Middleware
Redux Saga — это промежуточное программное обеспечение(middleware), которое берет на себя управление вашими действиями до того, как напрямую достигнет reducers.
Pабота без redux saga:
With Redux saga as middleware:
Action(s) → Redux Saga →Reducer(s)
Redux saga действует как промежуточное middleware, которое дает разработчикам возможность аккуратно разделить любую бизнес-логику, запросы xhr (широко известные как Ajax), манипуляции с данными или любые другие операции, которые могут показаться неприемлемыми для редукторов напрямую.
Зачем использовать Sagas
Давайте посмотрим на некоторые преимущества использования Saga:
Включение redux saga в существующее приложение:
вам понадобится babel, чтобы преобразовать его в код ES5
В приведенном выше коде мы пишем наш первый метод саги, который говорит, что всякий раз, когда запускается действие с типом: FETCH_REQUESTED, оно вызывает метод выборки данных. Точно так же мы можем зарегистрировать несколько методов в первой саге, например:
Напоследок напишем, что делает метод саги
Я знаю, что многие из вас подумают, что такое call и put. Мы постараемся понять это в следующем рассказе. На данный момент было бы достаточно знать, что эффект «call» принимает первые аргументы в качестве имени функции, которая будет выполняться, например: вызвать api.fetchUser с параметром action.payload.url и оставить его в качестве параметров, а «put» можно рассматривать как псевдоним для store.dispatch (<тип: “FETCH_SUCCEEDED”, данные: данные>);
В ближайшие недели я напишу следующую статью и расскажу больше об эффектах / асинхронных редукторах / тестировании и расширенном использовании.
Надеюсь, эта статья окажется для вас полезной.
Разбираемся в redux-saga: От генераторов действий к сагам
Любой redux разработчик расскажет вам, что одной из самых тяжелейших частей разработки приложений являются асинхронные вызовы — как вы будете обрабатывать реквесты, таймауты и другие коллбэки без усложнения redux действий(actions) и редьюсеров(reducers).
В этой статье я опишу несколько различных подходов к управлению асинхронностью в вашем приложении, начиная от простых подходов как redux-thunk, заканчивая более продвинутыми библиотеками вроде redux-saga.
Мы собираемся использовать React и Redux, поэтому будем полагать, что вы имеете хотя бы какое то представление о том как они работают.
Генераторы действий (Action creators)
Взаимодействие с API довольно частое требование в приложениях. Представьте, что нам необходимо показывать случайную картинку собаки, когда мы нажимаем на кнопку.
мы можем использовать Dog CEO API и что-то довольно простое вроде вызова fetch внутри генератора действия (action creator).
Нет ничего плохого в таком подходе. При прочих равных всегда лучше использовать более простой подход.
Однако, использование только Redux не дает нам достаточно гибкости. Ядро Redux это контейнер состояния (state container), который поддерживает только синхронные потоки данных.
На каждое действие, в хранилище (store) посылается объект, описывающий что произошло, затем вызывается редюсер (reducer) и состояние (state) сразу обновляется.
Но в случае асинхронного вызова, вам необходимо сначала дождаться ответа и затем уже, если не было ошибок, обновить состояние. А что если у вашего приложения есть некая сложная логика/workflow?
Для этого Redux использует промежуточные слои (middlewares). Промежуточный слой это кусок кода, который выполняется после отправки действия, но перед вызовом редюсера.
Промежуточные слои могут соединяться в цепочку вызовов для различной обработки действия (action), но на выходе обязательно должен быть простой объект (действие)
Для асинхронных операций, Redux предлагает использовать redux-thunk промежуточный слой.
Redux-thunk
Redux-thunk является стандартным путем выполнения асинхронных операций в Redux.
Для нашей цели, redux-thunk вводит понятие преобразователь(thunk), что является функцией, которая предоставляет отложенное выполнение, по необходимости.
Значение 3 сразу присваивается переменной x.
Однако, если у нас есть выражение наподобие
То суммирование выполняется не сразу, а только при вызове функции foo(). Это делает функцию foo преобразователем(thunk).
Redux-thunk позволяет генератору действия (action creator) отправлять функцию в дополнении к объекту, конвертируя таким образом генератор действия в преобразователь.
Ниже, мы перепишем предыдущий пример используя redux-thunk
На первый взгляд он не сильно отличается от предыдущей версии.
Преимуществом использования redux-thunk является то, что компонент не знает, что выполняется асинхронное действие.
Т.к. промежуточный слой автоматически передает функцию dispatch в функцию, которую возвращает генератор действий, то снаружи, для компонента, нет никакой разницы в вызове синхронных и асинхронных действий (и компонентам больше не нужно об этом беспокоиться)
Таким образом, с помощью механизма промежуточных слоев, мы добавили неявный слой (a layer of indirection), который дал нам больше гибкости.
Поскольку redux-thunk передает в возвращаемые функции методы dispatch и getState из хранилища (store) как параметры, то вы можете отсылать другие действия и использовать состояние (state) для реализации дополнительной логики и workflow.
Но что если у нас есть что-то более сложное, чтобы быть выраженным с помощью преобразователя (thunk), без изменения react компонента. В этом случае мы можем попробовать использовать другую библиотеку промежуточных слоев (middleware library) и получить больше контроля.
Давайте посмотрим как заменить redux-thunk на библиотеку, что может дать нам больше контроля — redux-saga.
Redux-saga
Redux-saga это библиотека нацеленная делать сайд-эффекты проще и лучше путем работы с сагами.
Саги это дизайн паттерн, который пришел из мира распределенных транзакций, где сага управляет процессами, которые необходимо выполнять транзакционным способом, сохраняя состояние выполнения и компенсируя неудачные процессы.
Чтобы узнать больше о сагах можно начать с просмотра Применения паттерна Сага от Caitie McCaffrey, ну а если вы амбициозны, то здесь Статья, которая первая описывает саги в отношении распределенных систем.
В контексте Redux, сага реализована как промежуточный слой (мы не можем использовать редюсеры потому что они должны быть чистыми функциями), который координирует и побуждает асинхронные действия (сайд-эффекты).
Redux-saga делает это с помощью ES6 генераторов
Генераторы (Generators) это функции которые могут быть остановлены и продолжены, вместо выполнения всех выражений в один проход.
Когда вы вызываете функцию-генератор, она возвращает объект-итератор. И с каждым вызовом метода итератора next() тело функции-генератора будет выполняться до следующего yield выражения и затем останавливаться.
Это делает асинхронный код проще для написания и понимания.
Для примера вместо следующего выражения:
С генераторами мы бы написали так:
Возвращаясь к redux-saga, если говорить в общем, мы имеем сагу чья работа это следить за отправленными действиями (dispatched actions).
Для координирования логики, которую мы хотим реализовать внутри саги, мы можем использовать вспомогательную функцию takeEvery для создания новой саги для выполнения операции.
Если есть несколько запросов, takeEvery стартует несколько экземпляров саги-рабочего (worker saga). Иными словами реализует конкурентность(concurrency) для вас.
Надо отметить, что сага-наблюдатель (watcher saga) является другим неявным слоем (layer of indirection), который дает больше гибкости для реализации сложной логики (но это может быть лишним для простых приложений).
Теперь мы можем реализовать fetchDogAsync() функцию (мы полагаем, что у нас есть доступ к методу dispatch)
Но redux-saga позволяет нам получить объект, который декларирует наше намерение произвести операцию, вместо результата выполнения самой операции. Иными словами, пример выше реализуется в redux-saga следующим образом:
(Прим. переводчика: автор забыл заменить самый первый вызов dispatch)
Вместо вызова асинхронного реквеста напрямую, метод call вернет только объект описывающий эту операцию и redux-saga сможет позаботиться о вызове и возвращении результатов в функцию-генератор.
Тоже самое касается и метода put. Вместо отправления действий (dispatch action) внутри функции-генератора, put возвращает объект с инструкциями для промежуточного слоя (middleware) — отправить действие.
Эти возвращаемые объекты называются Эффекты (Effects). Ниже пример эффекта возвращаемого методом call:
Работая с Эффектами, redux-saga делает саги скорее Декларативными, чем Императивными.
Декларативное программирование это стиль программирования, который пытается минимизировать или устранить сайд-эффекты, описанием что программа должна делать, вместо описания как она должна это делать.
Преимущество, которое это дает, и о чем говорят большинство людей, то что функцию, которая возвращает простой объект, гораздо проще тестировать, чем функцию, которая делает асинхронный вызов. Для тестирования, вам не нужно использовать реальное АПИ, делать фейки или мокать.
Для тестирования, вы просто итерируете функцию-генератор делая assert и сравниваете полученные значения.
Еще одно дополнительное преимущество это возможность легко объединять разные эффекты в сложный workflow.
Возвращаясь к нашему простому примеру, ниже полная реализация в redux-saga:
Когда вы нажимаете на кнопку, вот что происходит:
1. Отправляется действие FETCHED_DOG
2. Сага-наблюдатель (watcher saga) watchFetchDog получает это действие и вызывает сагу-рабочего (worker saga) fetchDogAsync.
3. Отправляется действие по отображению индикатора загрузки.
4. Происходит вызов API метода.
5. Отправляется действие по обновлению состояния (успех или провал)
Если вы считаете, что несколько неявных слоев и чуть-чуть дополнительной работы стоят этого, то redux-saga может дать вам больше контроля для обработки сайд-эффектов функциональным способом.
Заключение
Эта статья показала как реализовать асинхронные операции в Redux с помощью генераторов действий (action creators), преобразователей (thunks), и саг (sagas), идя от простого подхода к более сложному.
Redux не предписывает решение для обработки сайд-эффектов. Когда вы будете решать какому подходу следовать, вам необходимо учитывать сложность вашего приложения. Моя рекомендация — начинать с простого решения.
Также есть альтернативы redux-saga, которые стоит попробовать. Две самых популярных это redux-observable (который базируется на RxJS) и redux-logic (также базирующийся на RxJS наблюдателях, но дающий свободу писать вашу логику в других стилях).
Русские Блоги
Подробное объяснение фреймворка Redux-saga и учебник Demo
Подробное объяснение фреймворка Redux-saga и учебник Demo
Ранее мы объяснили базовое использование структуры redux и структуры dva, поскольку модуль эффектов в структуре dva предназначен для точек знаний в redux-saga. Некоторые студенты могут использовать среду dva, но они не очень знакомы с redux-saga. Давайте кратко расскажем об основном API фреймворка saga и о том, как его использовать с фреймворком redux
Редукс-сага официальный адрес
График демонстрационных эффектов
Пример демо-адреса
Автор redux-saga-Demo по-прежнему предоставляет две разные версии в соответствии с предыдущим стилем: простое CounterApp и немного более сложный TodoList
Что такое Редукс-сага?
Это означает, что логика приложения существует в двух местах:
Редукторы обрабатывают обновления состояния для действий
Sagas отвечает за координацию сложных или асинхронных операций
Sagas создается с помощью функции генератора. Если вы не знакомы с функцией генератора,Пожалуйста, ознакомьтесь с введением мистера Руана в Генератор
Sagas отличается от thunks. Thunks вызывается при создании действия, а Sagas вызывается только при запуске приложения (но изначально запущенные Sagas могут динамически вызывать другие Sagas). Sagas можно рассматривать как процесс, работающий в фоновом режиме. Прослушайте инициированное действие, а затем решите, что делать на основе этого действия: инициировать ли асинхронный вызов (например, запрос на выборку), или инициировать другие действия в хранилище, или даже вызывать другие саги
API-интерфейс фреймворка redux-saga
Во-первых, вспомогательная функция Saga
redux-saga предоставляет некоторые вспомогательные функции для извлечения задач при запуске определенных действий в хранилище. Позвольте мне сначала объяснить две вспомогательные функции: takeEvery и takeLatest
Например: каждый раз, когда мы нажимаем кнопку «Получить», мы запускаем действие FETCH_REQUESTED. Мы хотим получить некоторые данные с сервера, запустив задачу для обработки этого действия.
Сначала мы создадим задачу, которая выполнит асинхронное действие:
Затем запускайте вышеуказанную задачу каждый раз, когда начинается действие FETCH_REQUESTED.
Обратите внимание: Приведенная выше функция takeEvery может быть заменена следующей
В приведенном выше примере takeEvery позволяет одновременно запускать несколько экземпляров fetchData.В определенный момент мы можем запустить новую задачу fetchData, хотя один или несколько fetchData еще не завершены.
Если мы хотим получить ответ только на последний запрос (например, всегда показывать последнюю версию данных), мы можем использовать вспомогательную функцию takeLatest
В отличие от takeEvery, takeLatest разрешает выполнение только одной задачи fetchData в любое время, и эта задача является той, которая была запущена последней. Если задача уже была выполнена ранее, предыдущая задача будет автоматически отменена
Создатели эффекта
Фреймворк redux-saga предоставляет множество функций для создания эффектов, кратко расскажем о наиболее часто используемых в разработке.
take(pattern)
Функцию take можно понимать как прослушивание будущих действий. Она создает объект команды и сообщает промежуточному программному обеспечению, что нужно дождаться определенного действия. Генератор приостанавливает действие до тех пор, пока не будет инициировано действие, соответствующее шаблону. Take это блокирующий эффект
put(action)
Функция put используется для отправки эффекта действия. Вы можете просто понимать ее как функцию диспетчеризации в структуре приставки. После выполнения действия редуктор вычислит новое состояние и вернет его.Примечание: положить также блокирующий эффект
call(fn, …args)
Функцию вызова можно просто понимать как функцию, которая может вызывать другие функции, она дает промежуточному программному обеспечению команду вызывать функцию fn, а параметр args является параметром функции.Примечание:Функция fn может быть функцией Generator или обычной функцией, которая возвращает Promise. Функция call также является эффектом блокировки.
fork(fn, …args)
Функция fork аналогична функции call и используется для вызова других функций, но функция fork является неблокирующей, то есть программа завершена. yield fork(fn， args) После этой строки кода следующая строка кода выполняется немедленно, не дожидаясь, пока функция fn вернет результат.
select(selector, …args)
Функция выбора используется для инструктирования селектора, предоставляемого промежуточным программным обеспечением, для получения данных о состоянии в хранилище. Вы также можете просто понимать ее как ту же функцию, что и данные о состоянии в хранилище в структуре редукции: store.getState()
В-третьих, createSagaMiddleware ()
Функция createSagaMiddleware используется для создания промежуточного программного обеспечения Redux, связывая Sagas с Redux Store.
Каждая функция в sagas должна возвращать объект Generator, промежуточное программное обеспечение будет повторять этот Generator и выполнять весь эффект после выхода (эффект может рассматриваться как единица задачи redux-saga)
Динамическое выполнение саг, используется для выполнения саг после фазы applyMiddleware
Примечание: динамическое выполнение операторов саги middleware.run(sagas) Это должно быть выполнено после того, как хранилище создано. Если это выполнено перед хранилищем, программа сообщит об ошибке.
Используйте CounterApp Demo, чтобы увидеть конкретное использование redux-saga
index.js
sagas.js
reducer.js
Как видно из приведенной выше структуры кода, использование redux-saga по-прежнему относительно простое: по сравнению с CounterApp предыдущей структуры redux, существует дополнительный файл sagas, а файл redurs по-прежнему является предыдущим режимом использования.
резюме
Эта статья в основном объясняет общие API, наиболее часто используемые при разработке структуры redux-saga, и есть много менее часто используемых API. Пожалуйста, обратитесь к официальной документации redux-saga:http://leonshi.com/redux-saga-in-chinese/docs/api/index.html
Если студенты видят эту статью здесь, они все еще не знакомы с базовым использованием фреймворка redux-saga, и концепция нечеткая. Рекомендуется взглянуть на демонстрационный пример, предоставленный автором.
Предложение автора: Студенты могут объяснить предыдущее автораредукционная рамкаСравните со структурой redux-saga, чтобы узнать и понять, чтобы различия и связи между ними были более ясными.
Время благосостояния
Интеллектуальная рекомендация
Упражнения по поводу scipy (неделя 13)
Метод наименьших квадратов находит x и вычисляет остаток (используя функцию leastsq в scipy.optimize). Код: результат: Используйте функцию minim_scalar () в scipy.optimize, чтобы минимизировать (макси.
HTML js очищает значение в select, js контролирует добавление, удаление, изменение, выделение, очистку и определяет, существует ли элемент управления
Очистить выбранные элементы Если вы оставите первую строку [color = red] Оцените, есть ли элемент со значением = «paraValue» [/ color] [color = red] Добавить элемент [/ color] в опцию выбора.
Vuex разминка
— это объект, который может быть доступен все компоненты; Обобщенная
режим управления государством Применимый：1. Несколько компонентов публикации данных; 2. Несколько компонентов меняю.
VS2010 Компилированные результаты HellowOrld
Зеркало
Управляйте заданным двоичным деревом, преобразуйте его в зеркало источника два разветвленного дерева.