--- layout: docs title: Application Architecture ---

N1 uses Reflux, a slim implementation of Facebook's Flux Application Architecture to coordinate the movement of data through the application. Flux is extremely well suited for applications that support third-party extension because it emphasizes loose coupling and well defined interfaces between components. It enforces:

For more information about the Flux pattern, check out this diagram. For a bit more insight into why we chose Reflux over other Flux implementations, there's a great blog post by the author of Reflux.

There are several core stores in the application:

Most packages declare additional stores that subscribe to these Stores, as well as user Actions, and vend data to the package's React components.

Actions

In Flux applications, views fire Actions, which anyone in the application can subscribe to. Typically, Stores listen to actions to perform business logic and trigger updates to their corresponding views. For example, when you click "Compose" in the top left corner of N1, the React component for the button fires Actions::composeNewBlankDraft. The DraftStore listens to this action and opens a new composer window.

This approach means that your packages can fire existing Actions, like Actions::composeNewBlankDraft, or observe actions to add functionality. (For example, we have an Analytics package that also listens for Actions::composeNewBlankDraft and counts how many times it's been fired.) You can also define your own actions for use within your package.

For a complete list of available actions, see Actions.