Foundry376/Mailspring
1
1
Fork 0
mirror of https://github.com/Foundry376/Mailspring.git synced 2024-09-22 00:06:06 +08:00
Code Issues Packages Projects Releases Wiki Activity
Mailspring/docs/Architecture.md
Ben Gotow 7edafa3819 feat(docs): doc site generation, doc organization into sections, docs for actions and more 
Summary: Lots o docs

Test Plan: Run tests, review docs

Reviewers: evan

Reviewed By: evan

Differential Revision: https://review.inboxapp.com/D1496
2015-05-13 11:44:28 -07:00

3.1 KiB
Raw Blame History

Title Section Order
Application Architecture Guides 1

Nylas Mail 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:

  • Uni-directional data flow
  • Loose coupling between components

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:

  • {NamespaceStore}: When the user signs in to Nylas Mail, their auth token provides one or more namespaces. The NamespaceStore manages the available Namespaces, exposes the current Namespace, and allows you to observe changes to the current namespace.

  • {TaskQueue}: Manages {Task}s, operations queued for processing on the backend. Task objects represent individual API actions and are persisted to disk, ensuring that they are performed eventually. Each Task may depend on other tasks, and Tasks are executed in order.

  • {DatabaseStore}: The {DatabaseStore} marshalls data in and out of the local cache, and exposes an ActiveRecord-style query interface. You can observe the DatabaseStore to monitor the state of data in Nylas Mail.

  • {DraftStore}: Manages Drafts, which are {Message} objects the user is authoring. Drafts present a unique case in Nylas Mail because they may be updated frequently by disconnected parts of the application. You should use the {DraftStore} to create, edit, and send drafts.

  • {FocusedContentStore}: Manages focus within the main applciation window. The {FocusedContentStore} allows you to query and monitor changes to the selected thread, tag, file, etc.

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 Nylas Mail, 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}.