So far, we have been describing a solution that consists of only a product's topic and communication has only taken place from one view to another. In a more realistic application, we would have a lot of topics such as user management, orders, and so on; exactly what they are called is dependent on the domain of your application. As for views, it is quite possible that you will have a ton of views listening to another view, as in this example:
This describes an application that contains four different view components around their own topic. The Customers view contains a list of customers and it allows us to alter which customer we currently want to focus on. The other three supporting views show Orders, Messages, and Friends and their content depends on which customer is currently highlighted. From a Flux standpoint, the Orders, Messages, and Friends views can easily register with the store to know when things gets updated so they can fetch/refetch the data they need. However, imagine that the supporting views themselves want to support CRUD actions; then they would need their own set of constants, action creator, API, and store. So now your application would need to look something like this:
/customers
constants.js
customer-actions.js
customer-store.js
customer-api.js
/orders
constants.js
orders-actions.js
orders-store.js
orders-api.js
/messages
constants.js
messages-actions.js
messages-store.js
messages-api.js
/friends
constants.js
friends-actions.js
friends-store.js
friends-api.js
/common
dispatcher.js
Two interesting situations exist here:
- You have a self-contained view; all CRUD actions happen within it
- You have a view that needs to listen to other views
For the first situation, a good rule of thumb is to create its own set of constants, action creator, API, and store.
For the second situation, ensure your view registers itself with the store of that topic. For example, if the friends view needs to listen to the customer view, then it needs to register itself with the customer store.