RefluxJS — альтернативный взгляд на Flux архитектуру от Facebook

[akira]

Почему «экшн» не переводить как «действие»? Событие же, не переводите как «ивент»?

Юзер экшн вызывает ивет, что бы воркать со стореджем.

[FractalizeR]

Возможно, вы правы. Мне вообще сложно было с этим термином. С одной стороны, это действие, с другой — событие. Кроме того, действие — достаточно общий термин, который может означать вообще все что угодно. А мне нужно было, чтобы читатель понимал, что речь идет именно об объекте Action RefluxJS.

[akira]

так и называйте — «объект действия».

[FractalizeR]

Спасибо за совет, однако чем это лучше, чем «экшен»?

Пример, который вы привели с event, на мой взгляд, отличается от нашего случая. События — устоявшийся за много лет термин. И действительно глупо переводить «event» как «ивент». Однако, случай с actions Reflux мне кажется немного другим. Этот термин мне не кажется ясным, очевидным и устоявшимся. Кроме того, я не считаю себя таким уж ярым борцом за чистоту русского языка и иногда мне проще (ясности ради) использовать англицизм, чем судорожно думать об адекватном переводе.

[akira]

Конечно лучше т.к. он объясняет что это не просто действие, а объект Reflux.

[FractalizeR]

Я так не думаю, но спасибо за предложение.

[KlonD90]

А зачем экшен диспатчит сам себя? Что-то не то по-моему. Лучше уж диспатчер обогатить это тема.

[FractalizeR]

Я думаю, это сделано для удобства, чтобы диспетчер вообще убрать из схемы. Что-то вроде «идеального объекта» из ТРИЗ. Лучше, когда его нет, а его обязанности выполняет кто-то другой.

Мне нравится, как это сделано в Reflux. Довольно удобно. Вас не устраивает что-то конкретное или просто смущает то, что есть такое отклонение от Flux?

[KlonD90]

Ну чисто идеологически не верно. Action это некий атомарный меседж, а диспатчер это диспатчер если мы в рамках функциональных преобразований находимся.

[FractalizeR]

С точки зрения чистой идеологии, наверное, вы правы. Но ведь Reflux отличается и по идеологии от Flux. Это некоторый шаг в сторону. Скажем, хранилища в Reflux могут подписываться на другие хранилища.

Мне Reflux в этом смысле нравится больше.

[at0mic]

Что меня смутило, так это асинхронные экшены. Насколько я помню, на экшны не должна ложиться задача производить какие-либо операции, кроме как диспатчить самих себя. В примерах же видно, что экшн может выполнять действие и возвращать промис. Но ведь именно этим должен заниматься store, разве нет?

[FractalizeR]

Какой конкретно пример вы имеете ввиду?

[at0mic]

asyncResultAction.listenAndPromise( someAsyncOperation );
вот этот например

[FractalizeR]

Насколько я понимаю, там не совсем действие выполняется. Это просто shortcut для подписки на экшен и одновременной рассылки дочерних событий в зависимости от результата обработки.

asyncResultAction.listenAndPromise( someAsyncOperation );

Это означает, что производится подписка на событие asyncResultAction (в качестве обработчика используется someAsyncOperation). После того, как обработчик выполнится, будет произведена рассылка дочерних событий в зависимости от результата.

Не слишком канонично, но удобно.

[at0mic]

Я бы предостерег от использования. В крупном проекте последнее место, где будут искать какую-то БЛ — это экшны. Видимо автор не смог побороть искушения встроить педали туда, где они, в общем-то, не нужны.

[FractalizeR]

Да, согласен. Я у себя такое точно использовать не буду. Никто потом не поймет, что этот код делает вообще.

[dark_ruby]

так кто в итоге отвественнен за асинхронный вызов API — action или store?

[FractalizeR]

Какого API? Я вроде тут все написал.

[dark_ruby]

я имел ввиду коммуникации с сервером — но судя по вашим примерам, они происходят в сторах. спасибо.

[FractalizeR]

Да, в сторах. Только примеры не мои. Я их взял из документации по RefluxJS.

[dark_ruby]

а мне вот на SO не в сторах посоветовали это делать, но там правда и не про ReFlux речь, а про Flux

[FractalizeR]

Я не думаю, что:

• … есть один единственный правильный ответ на столь абстрактный вопрос
• … стоит тупо, не думая самостоятельно, делать то, что вам сказали на каком-то ресурсе, включая Хабр и SO

Скажем, в моей текущей задаче экшены уведомляют хранилище об изменении пользователем фильтров на странице. При изменении фильтров на страницу подгружаются новые данные. Сама логика вызова API довольно простая, поэтому я оставил ее в хранилище, поскольку хранилище аккумулирует в себе состояние фильтров и точно знает, когда нужно вызвать API (в некоторых случаях обращение к API вообще не выполняется).

Если бы код работы с API разросся, я бы его абстрагировал в отдельный модуль. Но в моем случае скорее всего именно хранилище обращалось бы к API через фасад.

Если у вас есть какой-то конкретный пример, давайте попробуем его разобрать, а не обсуждать сферического коня в вакууме.

[dark_ruby]

я не делаю тупо, что мне сказали — я рассматриваю и сравниваю варианты, в противном случае ни здесь ни на СО этих тредов бы не было. Однако я подозреваю что flux это некий паттерн, reflux — это реализация этого паттерна, хоть и не много не каконичная с точки зрения фб — но как паттерн он подразумевает общение с внешним API — так вот мне интересно какая его часть за это должна быть отвественна. Понятное дело что сам код работы с API необходимо выделить в отдельный модуль — но будет ли он вызван в экшене или сторе — для меня остается вопрос открытый.

[FractalizeR]

Прошу прощения, если мой ответ показался резким.

Я прочитал ваш вопрос и ответы к нему на SO. Я думаю, вы задали слишком общий вопрос. У вас есть какая-то конкретная ситуация, которую можно рассмотреть?

В самом экшене ничего вызвать нельзя, поскольку он не является полноценным объектом, который можно расширить (как хранилище). API можно вызывать в обработчике экшена (Action.listen(() => {})). Стоит ли это делать в обработчике или в хранилище, я полагаю, сильно зависит от ситуации.

[FractalizeR]

Кстати, возможно вас заинтересует вот эта статья. Автор описывает недостатки вызова API из Datastore.

[wheercool]

Поделюсь своим видением Flux. Для меня это один из вариантов реализации классического MVC паттерна (к-ый используется в ASP.NET MVC а не двусторонние байндинги и т.п.) где
Store = Model
Action = Controller
View = React Components

С точки зрения MVC Controller должен синхронизировать Model с внешними источниками данных. Model про них вообще ничего не должна знать. Поэтому я бы общение с внешним API поместил в Controller (Action)

[FractalizeR]

Action не является объектом. Это событие.

[wheercool]

Ну ок, если хотите формально, то в Flux Controller = Action Creator. Хотя сути то это не меняет )

[FractalizeR]

Да, я понял аналогию, но в Reflux нет Action creators в полном смысле. Произвольную логику, завязанную на action dispatch не поместить никуда. Разве что воспользоваться preEmit хуком у экшена, но это идеологически не совсем то будет.