Redux and The Command Pattern
There are two things I know for absolute certainty in the Software industry.
1. Frameworks Always Change
We’ve all been there.
The Vicious cycle:
If things always change, then as a Software Engineer your job is to constantly be learning and making the right bets in libraries or frameworks you decide to use.
2. Design Patterns are the foundation of Software Engineering
So if we know Frameworks always change, then we have to stick to the foundation of great software: Design Patterns.
Design patterns represent the best practices used by experienced software developers. Design Patterns teach you how to think. The main benefit of learning design patterns is that you can come up with solutions to your problems a lot faster and if your co-workers are aware of these patterns, everyone can speak the same language. Now I’m advocating Design Patterns, but they are not the end all be all of solutions. Its okay if you are not using every piece of a design pattern as long you have a better solution to your particular problem.
We can trace design patterns back to Christopher Alexander, author of Pattern Language. Alexander realized that certain methods, over time, created constructs to achieve efficiency. It was then, stemming from Alexander’s work, other publications started coming out. A great one to read is Design Patterns: Elements of Reusable Object-Oriented Software. This describes patterns that provided solutions to common software development problems.
The Command Pattern is a great pattern for architecting really clean decoupled systems. The motivation of this pattern is to execute some piece of business logic at some point in the future. The reason why I wanted to touch on the Command Pattern specifically is because I believe its the root pattern of Redux. Let’s get into the Command Pattern, then translate this to Redux.
There are several elements to the Command Pattern: the Receiver, Command, and the Executor.
The receivers job is to hold our business logic. When given a command, it knows how to fulfill that request.
Imagine we are running sales for Tesla’s new Model 3. Let’s write some code to describe how this would look:
In the traditional command pattern we would encapsulate this information in an object.
This contains information about the action being called, and its required parameters. It is represented as an object.
As you can see, the command defines the action. This corresponds to the method that is on our control object. In the example above, our sample command is taking the action “arrangeViewing”. It also passes the required params to arrangeViewing: model and carId.
The next thing we need is an interface to executes commands. Lets give our Sales control an execution function. For this function I wanted to write a generic executor that can accept and receiver. The executors job is pass the command to the receiver and call our business logic.
Now we can execute commands from anywhere at any time!
Make things happen
Thats it, now how does this compare to Redux!
The Store = The Receiver
The Store is instantiated with “reducers”, descriptions on how the Store change. These reducers are pure functions that when called return a new state rather than causing mutations in place. This allows you to have highly predictable and testable code.
The Action = The Command
The action object represents the description of the command and parameters it needs to execute our state change.
Dispatch = Executor
The difference between vanilla Flux and Redux, is the dispatch is a method of the store. The Store can dispatch actions to change the state of our application.
As you can see, pretty similar right!? Knowing the Command Pattern makes learning Redux a lot easier! Trust me!
Design Patterns in general help you ] stay rooted in your application architecture!
This post is part of a series called Mastering Meteor and Redux. You can read the course syllabus here. Follow me on Twitter @abhiaiyer and I’ll see you for the next chapter.