Flux architecture misunderstanding in example chat app

Question

I'm trying to understand the Flux example chat app. The authors mention this unidirectional data flow:

However, in the example app there are dependencies between Action Creators (ChatMesssageActionCreator) and Stores (MessageStore), and between Stores (MessageStore, ThreadStore) and Web API Utils (ChatMessageUtils), which seems to be against the unidirectional data flow rule:

Is it recommended to follow the given example, or should one design a better pattern?

Update

I figured out that the ChatMessageUtils doesn't belong to Web API Utils, so the two arrows from store shouldn't point there, therefore maybe they're okay. However the connection between the ActionCreators and the Store seems still strange.

Midsection

Answer 1

The example is a bit forced, and it was created with the purpose of trying to show how waitFor() works. The WebAPI aspect of the example is pretty half-baked and really should be revised.

However, even though MessageStore.getCreatedMessageData(text) passes a value to the store, it's still a getter. It's not setting data on the store. It's really being used as a utility method, and a good revision (pull request?) would be to move that method to a Utils module.

To improve upon the example for the real world, you might do a couple things:

• Call the WebAPIUtils from the store, instead of from the ActionCreators. This is fine as long as the response calls another ActionCreator, and is not handled by setting new data directly on the store. The important thing is for new data to originate with an action. It matters more how data enters the system than how data exits the system.

• Alternatively, you might want to have separate client-side vs. server-side IDs for the messages. There might be few advantages of this, like managing optimistic renderings. In that case, you might want to generate a client-side id in a Utils module, and pass that id along with the text to both the dispatched action and the WebAPIUtils.

All that said, yes the example needs revision.

Equiprobable

Thanks, detailed and comprehensible answer, now it's much cleaner! – Midsection

I'm still a bit confused about why a store would need to directly call the Web API Utils. Lets say that the store is in some state that requires some sort of server call. That state doesn't matter until something wants to use it. Therefore, you can just let a React component read that state and trigger an action based on that state. The bonus here is that the diagram remains true. Are there any ways that sticking to this would get someone into trouble? Of course there will always be exceptions, but I would imagine that would just be an anti-pattern to be used judiciously. – Avunculate

I'm trying to tackle this problem right now, so for any googlers sharing David Granado's concern, my reason for wanting to avoid doing a Check-Result & Call ActionCreator in the component layer is simple; It means a ton of boilerplate code scattered all throughout your components. If you're always going to call "getMessagesAction" when you have an uninitialized message store, you might as well put it in the central location where that fact becomes evident; in the Get method of your store. – Viperine