Understanding Flux pattern

Question

I'm actually studying the flux pattern and there's something that I can't understand concerning the stores.

What are they exactly?

I have read many articles, and it seems that it concerns the domain.

Does it mean that this is the "abstract" part related to api calls or backend calls?

It's not very clear for me.

Edit: Could it be the same thing as the angular factory? Fetching remote data, making a business task or store some app states (current user connected for example)?

Answer 1

Ok let me explain you from Step by Step

1 What is Flux?

• A pattern
• Centralized dispatcher
• Unidirectional data flows
• List item

They call it Flux for a reason too.

Flux Implementations

• Facebook’s Flux
• Alt
• Reflux
• Flummox
• NuclearJS
• Fluxible

A Chat with Flux

React : Hey Action, someone clicked this “Save Course” button.

Action: Thanks React! I registered an action creator with the dispatcher, so the dispatcher should take care of notifying all the stores that care.

Dispatcher :Let me see who cares about a course being saved. Ah! Looks like the Store has registered a callback with me, so I’ll let her know.

Store : Hi dispatcher! Thanks for the update! I’ll update my data with the payload you sent. Then I’ll emit an event for the React components that care.

React : Ooo! Shiny new data from the store! I’ll update the UI to reflect this!

---

Flux API

---

register(function callback) –“Hey dispatcher, run me when actions happen. -Store”

unregister(string id) –“Hey dispatcher, stop worrying about this action. -Store”

waitFor(array ids) –“Update this store first. –Store”

dispatch(object payload) -“Hey dispatcher, tell the stores about this action. -Action”

isDispatching() –“I’m busy dispatching callbacks right now.”

so the the question raise in our mind is

So Flux Is a Publish-Subscribe Model?

Not quite.

Differs in two ways:

1.Every payload is dispatched to all registered callbacks.

2.Callbacks can wait for other callbacks

Summary

Flux is a pattern for unidirectional data flows Actions encapsulate events Dispatcher is a central hub that holds callbacks Stores hold app state Many implementations

Answer 2

Looking up a simple example (https://github.com/facebook/flux/tree/master/examples/flux-todomvc/), “stores manage the application state for a particular domain within the application.“ That is, they contain data about the state of an aspect of the application and all the code to change it. Whenever there’s an new update from the Dispatcher, all the Stores see it, they decide how to update their data in response, and then they notify the Views that the data has changed. In the examples, Stores contain things like “unseen threads list” (where the Dispatcher notifies them that a new message has arrived or an old one has been read, and the Views display the message threads to the user) and “current playback time and state.”

More technically: they’re the intermediate layer of the framework that registers callbacks with the Dispatcher to receive updates, then notifies the Views when the state of the data changes. (The views might then send actions back to the Dispatcher.) There’s an abstract interface they implement, where each Store registers a callback with the Dispatcher and broadcasts events to the Views, but each Store seems to represent a specific domain in a concrete way. (Are there counterexamples?)

Answer 3

Stores are areas of the code that store application state and complex logic. A reason for them is that multiple views will likely use the same data, but display them in a different way, or display some but not all data for a particular domain. For example, a user logs in and you receive their first name, last name, email, photo, town, address number, phone number etc. This information is displayed on separate views. Rather than duplicating data across views we can use one Store called UserStore that stores the data for the user. This simplify's the system by giving "one place to make a change" whenever the logic or data stored must be changed. There are plenty of other reasons to use a Store, however that is the most obvious one I think.