JavaScript Architecture Flux Components

Flux: It is a JavaScript Architecture or pattern for UI which runs on a unidirectional data flow and has a centralized dispatcher. It is an application architecture designed to build client-side web apps. It is also one of the popular architectures that Facebook uses for building client-side web applications.  The Flux architecture is based on the following components.

Four major components of Flux:

1. Dispatcher: It coordinates actions and updates to stores.
2. Stores: It serves as a container for the app state and logic
3. Actions: It enables data passing to the dispatcher
4. Views: It is the same as the view in MVC architecture but in the context of React components.

With simple words if we understand the whole then in Flux architecture basically suppose a user clicked on something, the view creates actions; Actions creates a new data and send it to the dispatcher, here comes the work of the dispatcher, the dispatcher dispatches the action results to the appropriate store. Then the store updates the state that is based upon the result and sends an update to the view.

Data in a flux application flows in a single direction, or we can say that data in a flux flow in a unidirectional flow, the significance of unidirectional flow is that since the data flows through your application in a single direction we can have better control over it.

Flow:

Action => Dispatcher => Store => View

Dispatcher:

The dispatcher is the central hub that manages all Data flow in a flux application, essentially a registry of callbacks into the stores having no intelligence of its own, or we can say that it is a simple mechanism for distributing the actions to the stores.

• It is the epicenter of the data flow in any Flux application
• It controls what flows into the stores of the Flux application.
• It servers as the housing place for the callbacks that are created by the stores and which are linked to the dispatcher.
• Each store in the application creates a callback that registers it with the dispatcher.
• When an action creator sends a new action to the dispatcher, the dispatcher ensures that due to the callback provided all the registered stores get that action.

Note: The dispatcher is the ultimate arbiter of data dependencies.

Flux architecture is helpful for actions that included the effects of making the code clearer, updating other views, and debug by new developers. It also includes a singleton dispatcher and all actions are passing through the dispatcher. This design defends hard-to-debug cascading updates.

Stores:

The store is the hub of the application’s state and logic, the role is similar to a model in a traditional MVC. It registers itself with the dispatcher and provides it with a callback, and this receives action as the parameter.

• It contains the logic and state of the Flux application.
• Instead of representing a single data structure like a traditional model, the store in Flux can actually represent the state of management of many objects.
• It registers itself with a dispatcher and provides it with a callback.
• The callback passed to have a parameter that is known as the action, passed to it via the dispatcher.

Note: Stores are where the state lives, and only stores themselves can change this state.

Flux architecture uses Stores to cache any applications associated with data or state. It includes multiple stores. It also has logical handling capabilities and flexibility to decide what parts of your data to show publicly.

Actions:

When dispatcher exposes a method that allows us to trigger a dispatch to the stores, and to include a payload of data, which we call an action. Actions may also come from other places such as servers for example types data during initialization or when the server returns an error code or when the servers have updates to provide to the application.

• Actions define the methods, which will be called by the view.
• It is the form of data that has been dispatched to the stores.
• The methods contain arguments, which contain further instructions on how the view wants to change the store.
• The action is responsible for translating dispatch calls to events; which are understandable by the Stores.

Note: If it’s not an action, it can’t happen.

Actions in Flux architecture are collections of methods that are called within or inside views to send actions to the Dispatcher. It is one of the actual payloads that are delivered via the dispatcher. The action-type example typesets are used to define what action must occur and are sent along with the action data.

Views:

It’s not a technical part of Flux but at the same time, views are obviously a critical part of our application. It is mostly understood as the part of our architecture that’s responsible for displaying data to the user, It’s the last stop of our data flow architecture. Views exist outside of flux but are constrained by the unidirectional nature of Flux.

• It is simply the composition of the components.
• It is the part of the architecture that’s responsible for displaying data to the user.
• The view layer is the layer where React fits into this architecture.

Note: The only way data-flows out of a view is by dispatching an action.

It is basically just a React Components that listens to changes events and retrieves applications’ state from stores hence pass that data down to their child components.