12

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)?

3
  • 1
    A link to what precisely you're talking about would be helpful. Do you mean this "flux pattern"? fluxxor.com/what-is-flux.html
    – DougM
    Sep 1 '15 at 15:44
  • Flux is nothing more that the publish / subscribe pattern with a constraint that all data go through the dispatcher first. It guarantees the data does not go backwards (and cause confusion). Things like "Store", "Action" etc are just another way of saying Components of the system, and the Data that gets passed around. Oct 14 '19 at 2:56
24

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

enter image description here

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

5
  • My first problem is that state allows application to have different data of the remote api entities :-/
    – mfrachet
    Sep 9 '15 at 9:54
  • what do you mean by state allows? wherever emit change called it will called the React View and again called state change method Sep 9 '15 at 10:28
  • Admitting that I build an application with flux . I m dealing with an API and then I save the data inside of my stores. What if a users modifiy the remote data ? I will have a difference between both client and server
    – mfrachet
    Sep 9 '15 at 12:43
  • now where can i find why. If all dispatcher and store are gonna do is forward to view, then why can't action update view directly. why there are middlemen Aug 3 '16 at 15:53
  • @MuhammadUmer: Dispatcher is one for the application and store is based on component in application so to remove the redundancy middlemen were introduced Aug 4 '16 at 6:29
1

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?)

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.