Why should I use Actions in Flux?

Question

The application I'm developing was originally built using Flux.

However, over time, the application has become more difficult to maintain. There was a very large number of actions . And usually one action is listened only in one place (store).

Actions allow you not to write all the code of the event handler in one place. So instead:

store.handleMyAction('ha') another.handleMyAction('ha') yetAnotherStore.handleMyAction('ha') 

I can write:

 actions.myAction('ha') 

But I never use actions in this way . I am pretty sure that this is not the problem of my application.

Every time I call an action, I could just call store.onSmthHappen instead of action.smthHappen .

Of course, there are exceptions when one action is processed in several places. But when this happens, it seems that something went wrong.

How about I call methods directly from the store instead of calls? Will my application not be so flexible? No! Only renaming occurs (with rare exceptions). But at what price! It becomes much more difficult to understand what is happening in the application with all these actions. Every time I track the processing of complex actions, I have to find in the stores where they are processed. Then in these stores I have to find the logic that triggers another action. Etcetera.

Now I come to my decision:

There are controllers that directly call methods from the repositories. All logic is handled in the store. Also, stores call WebAPI (usually one store that belongs to one WebAPI). If the event should be processed in several repositories (usually sequentially ), then the controller processes this by organizing promises returned from stores. Some of the sequences (commonly used) in private methods are on their own. And the controller method can use them as a simple part of processing. Therefore, I will never duplicate the code .

Controller methods return nothing ( one-way flow ).

In fact, the controller does not contain logic for data processing. It indicates only where and in what order .

You can see an almost complete picture of the data processing in the Store. There is no logic in stores on how to interact with other stores (with flux, it looks like a many-to-many relationship , but only through actions). Now the repository is a very connected module that is responsible only for the domain model logic (collection).

The main (in my opinion) advantages of the stream are still here.

As a result, there are stores that are only a true source of data . Components can subscribe to stores. And the component names the same methods as before, but uses the controller instead of actions . Reagent interaction has not changed at all .

In addition, event handling becomes apparent. Now I can just look at the handler in the controller, and everything becomes clear, and it is much easier to debug it.

The question arises:

Why were the actions created in the thread? And what are their advantages that I missed?

Answer 1

Actions that are implemented to capture a certain interaction in the view or from the server, which can then be sent to as many different stores as you like. The developers explained this using facebookchat as an example. There is messageStore and threadstore. When the action, for example. messagePost was sent, and it was sent to both stores doing different jobs to update its attributes. Threadstore increased the number of unread messages, and messageStore added a new message to its message file.

Thus, its basic direction is one action for executing data in more than one repository.

Answer 2

I had the same questions and thought processes as you, and now I started using Flummox , which makes it cleaner to have a Flux architecture.

I define my actions in the same file where I define my Store, and this is close enough. I can still subscribe to the dispatcher to register events, so that I can see all the actions being called, and I have the opportunity to create actions with several repositories if necessary.

It comes with a beautiful FluxComponent, which allows you to wrap all the code associated with the store in one place, so that its children are inactive components that are updated with changes in the store, for example

  <FluxComponent connectToStores={['storeA', 'storeB']}> <InnerComponent /> </FluxComponent> 

Maintaining the Flux architecture (it uses Facebook Flux behind the scenes) will hopefully make it easy to use other technologies such as GraphQL .