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
   

   View Slide

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
   

   View Slide

3. I’m Ryan Haase
   Software Engineer @ Mavenlink
   I Love Design Patterns and Dogs
   GitHub: ryandhaase
   Twitter: @ryandhaase
   Email: rhaase@mavenlink.com
   

   View Slide

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

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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….
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

23. View Slide

24. Thanks, I’m Ryan Haase
    Software Engineer @ Mavenlink
    I Love Design Patterns and Dogs
    GitHub: ryandhaase
    Twitter: @ryandhaase
    Email: rhaase@mavenlink.com
    

    View Slide