The SAM pattern is a reactive functional pattern that clearly separates the model from the view. It is based on the Temporal Logic of Actions (TLA+), which is a robust formal specification to model, describe, analyse and verify systems. Some key goals of SAM are:
- Unidirectional data flow
- Composition
- Explicit mutation
- Decoupling from API calls
The model contains the application state (store) and is responsible to make it persistent. Any change to the store must be proposed / presented to the model, which then decides to accept or reject them. When the store changes, everyone who needs to learn about the new store, gets notified.
The state translates the model's store into a desired representation. Despite its name, it does not hold any state, but is a pure function that receives the model / store as an input and returns suitable representation (e.g. composed values). In addition to transform the data, the state also processes the next action predicate.
The next action predicate is a function that represents an automatic action that needs to be invoked under a given condition (e.g. turning off the engine of a car after it has reached its destination).
An action is a function that receives some data and creates the data (proposal) that is presented to the model. An action may enforce the completeness and structure of the data, but it should not make any assumption about the validity of the data (the model is supposed to do that).
The state representation may be in any form (e.g. HTML, JSON, plain text, etc.) using the technology the user prefers. These should simply display the data they receive. A good example for this are functional stateless React components. It is also important to understand that the view itself is not a response to a previous view. It simply renders the data without knowing how the data has been produced. For instance when a part of the view is clicked, it may trigger an action which may or may not change the state representation, but the view does not expect or wait for a response to that action.
Model-View-Controller is a pattern that separates the presentation layer from the business logic.
- Model: Holds and manages data
- View: Displays the data
- Controller: Handles interactions and other actions
The MVC pattern is a frequently discussed and misunderstood pattern. There are many different interpretations that wire the components differently. The original implementation in Smalltalk uses the following relation:
But many MVC frameworks for the web put the controller in charge, making it responsible for choosing the correct view and interacting with the model.
Besides the different interpretations there are also variations that are grouped under the MV* family (e.g. Model-View-Presenter (MVP) or Model-View-ViewModel (MVVM)). - Some MV* variations
Flux is an application architecture that Facebook created to build scalable client-side web applications. They moved away from the MVC pattern because it was really complicated and difficult to maintain for their large codebase. Facebook has been criticised for misunderstanding MVC or using it wrong and that the Flux diagram is essentially what MVC is supposed to look like just with different labels.
- Dispatcher: Singleton that manages all data flow by sending issued actions to the stores via the registered callbacks.
- Stores: Contain application's state and logic.
- Views: Display the data and re-render when the data changes. Can also invoke actions (user interactions).
- Actions: Simple objects that trigger a dispatch with the included payload.
Elm is a functional programming language inspired by Haskell that compiles to JavaScript. It is meant for creating web apps and even has its own virtual DOM implementation and therefore competes with React.
Elm enforces the Model-Update-View architecture (also referred to as the Elm architecture), but the architecture can be used to structure any front-end project.
- Model: The state of the application
- Update: Actions that update the model with the signature
(action, state) => statewhich returns a new state since everything is immutable. - View: HTML Display of the state
Redux is inspired by Flux, but avoids its complexity by applying some concepts of the Elm architecture.
Note: There is no dispatcher in Redux, only the store.dispatch(action)
function, that triggers the action, which is the only way to change the state.
- Store: Single source of truth (single object tree), which is read only. A new state is created every time.
- Actions: Plain objects describing the intent to change the state. Only way to get data into the store.
- Reducers: Pure functions that take the previous state and an action, and return the next state.
- Theoretical background
- TLA+
- Paxos Protocol
- Comparison to existing patterns / architectures
- MVC or MV* in general
- Flux / Redux
- Elm (Model-Update-View)
- Evaluation of SAM
- Strengths and weaknesses / Pros and cons
- Practicality
- Possible improvements
- Concrete examples
- Library
- Keep it small
- Make it pleasant to use
- Maybe provide bindings for popular view libraries (similar to react-redux)
- Reimplement existing applications
- Front-end and back-end
- Compare the approaches
- Isomorphic JavaScript
- Library