Translating Redux for the Object-Oriented Mind
For developers coming from an object-oriented background, Redux often feels like a puzzle wrapped in functional programming jargon. Yet the underlying concept becomes much less mysterious once you map it onto familiar patterns. The core idea: manage all application state in one centralized, immutable state tree. Below is an attempt at explaining it through that lens, alongside a complete working sample project that uses Angular 2 with @ngrx/store, and a more detailed write-up over at Heise Online.
For the English version of this article, please see the original post.
- At first glance, an action resembles a Command. The key distinction is that the execution logic isn't inside the action itself; instead, it lives in multiple reducers, each responsible for a major branch of the state tree. This means several reducers can respond to the same action, which is a significant departure from the classic command pattern's one-to-one mapping.
- The benefits of the Command pattern are still fully retained, including straightforward undo/redo via stacks, logging, and the ability to bundle multiple commands into a batch.
- The interaction between the store and the application follows the CQRS principle. Commands are described as actions, separating the act of issuing a change from the way it's processed.
- For reading data from the state tree, the Observer pattern is the standard mechanism. The application subscribes to specific portions of the tree, and each observer is set up to monitor a particular branch, ensuring it only gets notified when that slice changes.
- To make change detection efficient after reducers run, the state tree is treated as immutable. This lets the store perform a quick reference check per observer instead of having to recursively compare an entire subtree, which would be far more costly.
