Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ryan D Haase
November 27, 2017

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

Ryan D Haase

November 27, 2017
Tweet

Other Decks in Programming

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: [email protected]

    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: [email protected]

    View Slide