Комментарии 29
Почему «экшн» не переводить как «действие»? Событие же, не переводите как «ивент»?
Юзер экшн вызывает ивет, что бы воркать со стореджем.
+1
Возможно, вы правы. Мне вообще сложно было с этим термином. С одной стороны, это действие, с другой — событие. Кроме того, действие — достаточно общий термин, который может означать вообще все что угодно. А мне нужно было, чтобы читатель понимал, что речь идет именно об объекте Action RefluxJS.
0
так и называйте — «объект действия».
+1
Спасибо за совет, однако чем это лучше, чем «экшен»?
Пример, который вы привели с event, на мой взгляд, отличается от нашего случая. События — устоявшийся за много лет термин. И действительно глупо переводить «event» как «ивент». Однако, случай с actions Reflux мне кажется немного другим. Этот термин мне не кажется ясным, очевидным и устоявшимся. Кроме того, я не считаю себя таким уж ярым борцом за чистоту русского языка и иногда мне проще (ясности ради) использовать англицизм, чем судорожно думать об адекватном переводе.
Пример, который вы привели с event, на мой взгляд, отличается от нашего случая. События — устоявшийся за много лет термин. И действительно глупо переводить «event» как «ивент». Однако, случай с actions Reflux мне кажется немного другим. Этот термин мне не кажется ясным, очевидным и устоявшимся. Кроме того, я не считаю себя таким уж ярым борцом за чистоту русского языка и иногда мне проще (ясности ради) использовать англицизм, чем судорожно думать об адекватном переводе.
+1
А зачем экшен диспатчит сам себя? Что-то не то по-моему. Лучше уж диспатчер обогатить это тема.
0
Я думаю, это сделано для удобства, чтобы диспетчер вообще убрать из схемы. Что-то вроде «идеального объекта» из ТРИЗ. Лучше, когда его нет, а его обязанности выполняет кто-то другой.
Мне нравится, как это сделано в Reflux. Довольно удобно. Вас не устраивает что-то конкретное или просто смущает то, что есть такое отклонение от Flux?
Мне нравится, как это сделано в Reflux. Довольно удобно. Вас не устраивает что-то конкретное или просто смущает то, что есть такое отклонение от Flux?
0
Ну чисто идеологически не верно. Action это некий атомарный меседж, а диспатчер это диспатчер если мы в рамках функциональных преобразований находимся.
0
Что меня смутило, так это асинхронные экшены. Насколько я помню, на экшны не должна ложиться задача производить какие-либо операции, кроме как диспатчить самих себя. В примерах же видно, что экшн может выполнять действие и возвращать промис. Но ведь именно этим должен заниматься store, разве нет?
0
Какой конкретно пример вы имеете ввиду?
0
asyncResultAction.listenAndPromise( someAsyncOperation );
вот этот например
вот этот например
0
Насколько я понимаю, там не совсем действие выполняется. Это просто shortcut для подписки на экшен и одновременной рассылки дочерних событий в зависимости от результата обработки.
Это означает, что производится подписка на событие asyncResultAction (в качестве обработчика используется someAsyncOperation). После того, как обработчик выполнится, будет произведена рассылка дочерних событий в зависимости от результата.
Не слишком канонично, но удобно.
asyncResultAction.listenAndPromise( someAsyncOperation );
Это означает, что производится подписка на событие asyncResultAction (в качестве обработчика используется someAsyncOperation). После того, как обработчик выполнится, будет произведена рассылка дочерних событий в зависимости от результата.
Не слишком канонично, но удобно.
0
Я бы предостерег от использования. В крупном проекте последнее место, где будут искать какую-то БЛ — это экшны. Видимо автор не смог побороть искушения встроить педали туда, где они, в общем-то, не нужны.
0
так кто в итоге отвественнен за асинхронный вызов API — action или store?
0
Какого API? Я вроде тут все написал.
0
я имел ввиду коммуникации с сервером — но судя по вашим примерам, они происходят в сторах. спасибо.
0
Да, в сторах. Только примеры не мои. Я их взял из документации по RefluxJS.
0
Я не думаю, что:
Скажем, в моей текущей задаче экшены уведомляют хранилище об изменении пользователем фильтров на странице. При изменении фильтров на страницу подгружаются новые данные. Сама логика вызова API довольно простая, поэтому я оставил ее в хранилище, поскольку хранилище аккумулирует в себе состояние фильтров и точно знает, когда нужно вызвать API (в некоторых случаях обращение к API вообще не выполняется).
Если бы код работы с API разросся, я бы его абстрагировал в отдельный модуль. Но в моем случае скорее всего именно хранилище обращалось бы к API через фасад.
Если у вас есть какой-то конкретный пример, давайте попробуем его разобрать, а не обсуждать сферического коня в вакууме.
- … есть один единственный правильный ответ на столь абстрактный вопрос
- … стоит тупо, не думая самостоятельно, делать то, что вам сказали на каком-то ресурсе, включая Хабр и SO
Скажем, в моей текущей задаче экшены уведомляют хранилище об изменении пользователем фильтров на странице. При изменении фильтров на страницу подгружаются новые данные. Сама логика вызова API довольно простая, поэтому я оставил ее в хранилище, поскольку хранилище аккумулирует в себе состояние фильтров и точно знает, когда нужно вызвать API (в некоторых случаях обращение к API вообще не выполняется).
Если бы код работы с API разросся, я бы его абстрагировал в отдельный модуль. Но в моем случае скорее всего именно хранилище обращалось бы к API через фасад.
Если у вас есть какой-то конкретный пример, давайте попробуем его разобрать, а не обсуждать сферического коня в вакууме.
0
я не делаю тупо, что мне сказали — я рассматриваю и сравниваю варианты, в противном случае ни здесь ни на СО этих тредов бы не было. Однако я подозреваю что flux это некий паттерн, reflux — это реализация этого паттерна, хоть и не много не каконичная с точки зрения фб — но как паттерн он подразумевает общение с внешним API — так вот мне интересно какая его часть за это должна быть отвественна. Понятное дело что сам код работы с API необходимо выделить в отдельный модуль — но будет ли он вызван в экшене или сторе — для меня остается вопрос открытый.
0
Прошу прощения, если мой ответ показался резким.
Я прочитал ваш вопрос и ответы к нему на SO. Я думаю, вы задали слишком общий вопрос. У вас есть какая-то конкретная ситуация, которую можно рассмотреть?
В самом экшене ничего вызвать нельзя, поскольку он не является полноценным объектом, который можно расширить (как хранилище). API можно вызывать в обработчике экшена (Action.listen(() => {})). Стоит ли это делать в обработчике или в хранилище, я полагаю, сильно зависит от ситуации.
Я прочитал ваш вопрос и ответы к нему на SO. Я думаю, вы задали слишком общий вопрос. У вас есть какая-то конкретная ситуация, которую можно рассмотреть?
В самом экшене ничего вызвать нельзя, поскольку он не является полноценным объектом, который можно расширить (как хранилище). API можно вызывать в обработчике экшена (Action.listen(() => {})). Стоит ли это делать в обработчике или в хранилище, я полагаю, сильно зависит от ситуации.
0
Кстати, возможно вас заинтересует вот эта статья. Автор описывает недостатки вызова API из Datastore.
0
Поделюсь своим видением Flux. Для меня это один из вариантов реализации классического MVC паттерна (к-ый используется в ASP.NET MVC а не двусторонние байндинги и т.п.) где
Store = Model
Action = Controller
View = React Components
С точки зрения MVC Controller должен синхронизировать Model с внешними источниками данных. Model про них вообще ничего не должна знать. Поэтому я бы общение с внешним API поместил в Controller (Action)
Store = Model
Action = Controller
View = React Components
С точки зрения MVC Controller должен синхронизировать Model с внешними источниками данных. Model про них вообще ничего не должна знать. Поэтому я бы общение с внешним API поместил в Controller (Action)
0
Action не является объектом. Это событие.
0
Ну ок, если хотите формально, то в Flux Controller = Action Creator. Хотя сути то это не меняет )
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RefluxJS — альтернативный взгляд на Flux архитектуру от Facebook