At the core of the Flux pattern is a unidirectional data flow. It uses some core concepts to achieve this flow. The main idea is when an event is created on a UI, through the interaction of a user, an action is created. This action consists of an intent and a payload. The intent is what your are trying to achieve. Think of the intent as a verb. Add an item, remove an item, and so on. The payload is the data change that needs to happen to achieve our intent. If we are trying to add an item, then the payload is the newly created item. The action  is then propagated in the flow with the help of a dispatcher. The action and its data eventually end up in a store.

The concepts that make up the Flux pattern are:

• Action and action creators, where we set up an intention and a payload of data
• The dispatcher, our spider in the web that is able to send messages left and right
• The store, our central place for state and state management

All these together form the Flux pattern and promote unidirectional data flow. Consider the following diagram:

What is depicted here is a undirectional data flow. The data flows from View to Action, from Action to Dispatcher, from Dispatcher to Store. There are two possible ways that the flow is triggered:

• The application is loaded a first time, in which the data is pulled from the Store to populate the view.
• A user interaction happens in the view that leads to an intent to change something. The intent is encapsulated in an Action, and thereafter sent to the Store, via the Dispatcher. At the Store, it may be persisted in a database, through an API or saved as an application state, or both.

Let's dive into each concept in more detail, together with highlighting some code examples, in the upcoming sections.