Life is a Slice of State React/Redux Patterns for a New Generation 

Why Care About Design Patterns? ● Solid and consistent design patterns are crucial to writing maintainable, readable, and reusable code ● Speed up development time by providing well tested, and proven development paradigms ● They should solve challenges, and provide structure to common problems with regards to your codebase and/or team 

I’m Ryan Haase Software Engineer @ Mavenlink I Love Design Patterns and Dogs GitHub: ryandhaase Twitter: @ryandhaase Email: [email protected] 

Redux Data Flow ● Unidirectional data flow ● Consistent data lifecycle ● View -> Actions -> Reducers -> Store -> View Action Reducer Store View 

Redux Actions ● Actions are plain old objects ● Send payloads of data from your application to your store ● Used to handle non-deterministic logic like async requests ● Event Emitters / Event Triggers 

Reducers ● When dispatched, the actions indicate that something has happened but not how the state should change in response ● Reducers are pure functions that take the previous state and an action, and return the next state ● No side effects ● No mutations 

Store ● An object containing the whole state of an application (State Tree) ● The state is read only, and can only be changed through dispatching actions 

Selectors ● Sit between the store and view layer ● Act as “getters” that allow us to retrieve a slice from the state tree ● Derive Computations ● Single source of truth 

Why Explore New Design Patterns? ● Consistent design patterns that are maintainable, readable, and reusable code ● Well tested, and proven development paradigms ● Solve challenges, and provide structure to common problems ● Maintainable ● Readable ● Reusable ● Testable ● Well Structured 

Selectors: Pattern #1 ● Defining Selectors within Containers ○ Maintainable ✘ ○ Readable ✘ ○ Reusable ✘ ○ Testability ✘ ○ Well Structured ✘ 

Selectors: Pattern #2 ● Import Selectors from External Location ○ Maintainable ✘ ○ Readable ✔✘ ○ Reusable ✔ ○ Testability ✔ ○ Well Structured ✔✘ 

Selectors: Pattern #3 ● Colocating Selectors with Reducers ○ Maintainable ✔ ○ Readable ✔ ○ Reusable ✔✘ ○ Testability ✔ ○ Well Structured ✔ 

New Pattern: Model “Types” ● Define “getter” Selectors as a Model “Type” ● Colocate Computation Selectors ○ Maintainable ✔ ○ Readable ✔ ○ Reusable ✔✘ ○ Testability ✔ ○ Well Structured ✔ 

Model “Types”: Decorator ● Don’t Repeat Yourself! ● Extract away common selectors for accessing the state tree 

Model “Types”: Dry it Up! ● Decorate Model “Types” ○ Maintainable ✔ ○ Readable ✔ ○ Reusable ✔ ○ Testability ✔ ○ Well Structured ✔ 

Model “Types”: PropTypes ● Don’t Repeat Yourself! ● Single source of truth for an object's prop type shape 

Model “Types”: SpecExample ● Don’t Repeat Yourself! ● Factory for building spec examples throughout test suite 

Model “Types”: CRUD Actions ● Don’t Repeat Yourself! ● Whether we are creating, reading, updating, or destroying, the only thing that changes, is the object we are working with…. 

Model “Types”: CRUD Actions ● Decorating our Model “Types” with our common CRUD Actions enforces: ○ Consistency ○ Readability ○ Maintainable ○ Reusability 

Recap: Model “Types” Pattern ● Maintainable ✔ ○ Structural Design Pattern (Facade Pattern) ● Readable ● Reusable ● Testability ● Well Structured 

Recap: Model “Types” Pattern ● Maintainable ✔ ● Readable ✔ ○ Focused Methods/Functions ○ Intention-Revealing Interfaces ● Reusable ● Testability ● Well Structured 

Recap: Model “Types” Pattern ● Maintainable ✔ ● Readable ✔ ● Reusable ✔ ○ Selectors ○ Prop Types ○ CRUD Actions ○ Spec Examples - Factories ● Testability ● Well Structured 

No content

Thanks, I’m Ryan Haase Software Engineer @ Mavenlink I Love Design Patterns and Dogs GitHub: ryandhaase Twitter: @ryandhaase Email: [email protected]