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

Solid design patterns are crucial to building maintainable, readable, and reusable code. Implementing design patterns that are well tested, and proven development paradigms, allows us to write elegant and reusable solutions to common challenges within an application.

While there are many common patterns that are customarily used, it is important to examine the tradeoffs of each with regards to the codebase and/or team you are currently working within. Don't be afraid to explore and develop your own - there is no "one size fits all pattern", especially when working with relatively new libraries and frameworks.

During this talk, we will cover the Redux Data Lifecycle, some core concepts for React/Redux applications, weigh in on some common design patterns around accessing and managing the state tree and explore some new patterns we are implementing at Mavenlink.

Video: https://youtu.be/8EbOBImQK-0

This talk was given @ Diversity in Tech: Women Level Up (https://www.meetup.com/Maven-Diversity-in-Tech-Women-Level-Up), on November 27, 2017

Transcript

1. Life is a Slice of State React/Redux Patterns for a New Generation
2. 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
3. I’m Ryan Haase Software Engineer @ Mavenlink I Love Design Patterns and Dogs GitHub: ryandhaase Twitter: @ryandhaase Email: rhaase@mavenlink.com
4. Redux Data Flow • Unidirectional data flow • Consistent data lifecycle • View -> Actions -> Reducers -> Store -> View Action Reducer Store View
5. 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
6. 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
7. 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
8. 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
9. 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
10. Selectors: Pattern #1 • Defining Selectors within Containers ◦ Maintainable ✘ ◦ Readable ✘ ◦ Reusable ✘ ◦ Testability ✘ ◦ Well Structured ✘
11. Selectors: Pattern #2 • Import Selectors from External Location ◦ Maintainable ✘ ◦ Readable ✔✘ ◦ Reusable ✔ ◦ Testability ✔ ◦ Well Structured ✔✘
12. Selectors: Pattern #3 • Colocating Selectors with Reducers ◦ Maintainable ✔ ◦ Readable ✔ ◦ Reusable ✔✘ ◦ Testability ✔ ◦ Well Structured ✔
13. New Pattern: Model “Types” • Define “getter” Selectors as a Model “Type” • Colocate Computation Selectors ◦ Maintainable ✔ ◦ Readable ✔ ◦ Reusable ✔✘ ◦ Testability ✔ ◦ Well Structured ✔
14. Model “Types”: Decorator • Don’t Repeat Yourself! • Extract away common selectors for accessing the state tree
15. Model “Types”: Dry it Up! • Decorate Model “Types” ◦ Maintainable ✔ ◦ Readable ✔ ◦ Reusable ✔ ◦ Testability ✔ ◦ Well Structured ✔
16. Model “Types”: PropTypes • Don’t Repeat Yourself! • Single source of truth for an object's prop type shape
17. Model “Types”: SpecExample • Don’t Repeat Yourself! • Factory for building spec examples throughout test suite
18. 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….
19. Model “Types”: CRUD Actions • Decorating our Model “Types” with our common CRUD Actions enforces: ◦ Consistency ◦ Readability ◦ Maintainable ◦ Reusability
20. Recap: Model “Types” Pattern • Maintainable ✔ ◦ Structural Design Pattern (Facade Pattern) • Readable • Reusable • Testability • Well Structured
21. Recap: Model “Types” Pattern • Maintainable ✔ • Readable ✔ ◦ Focused Methods/Functions ◦ Intention-Revealing Interfaces • Reusable • Testability • Well Structured
22. Recap: Model “Types” Pattern • Maintainable ✔ • Readable ✔ • Reusable ✔ ◦ Selectors ◦ Prop Types ◦ CRUD Actions ◦ Spec Examples - Factories • Testability • Well Structured
24. Thanks, I’m Ryan Haase Software Engineer @ Mavenlink I Love Design Patterns and Dogs GitHub: ryandhaase Twitter: @ryandhaase Email: rhaase@mavenlink.com