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

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

E680be5667d7537097b2238f70e48d6a?s=128

Ryan D Haase

November 27, 2017
Tweet

Transcript

  1. 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
  2. 3.

    I’m Ryan Haase Software Engineer @ Mavenlink I Love Design

    Patterns and Dogs GitHub: ryandhaase Twitter: @ryandhaase Email: rhaase@mavenlink.com
  3. 4.

    Redux Data Flow • Unidirectional data flow • Consistent data

    lifecycle • View -> Actions -> Reducers -> Store -> View Action Reducer Store View
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 10.

    Selectors: Pattern #1 • Defining Selectors within Containers ◦ Maintainable

    ✘ ◦ Readable ✘ ◦ Reusable ✘ ◦ Testability ✘ ◦ Well Structured ✘
  10. 11.

    Selectors: Pattern #2 • Import Selectors from External Location ◦

    Maintainable ✘ ◦ Readable ✔✘ ◦ Reusable ✔ ◦ Testability ✔ ◦ Well Structured ✔✘
  11. 12.

    Selectors: Pattern #3 • Colocating Selectors with Reducers ◦ Maintainable

    ✔ ◦ Readable ✔ ◦ Reusable ✔✘ ◦ Testability ✔ ◦ Well Structured ✔
  12. 13.

    New Pattern: Model “Types” • Define “getter” Selectors as a

    Model “Type” • Colocate Computation Selectors ◦ Maintainable ✔ ◦ Readable ✔ ◦ Reusable ✔✘ ◦ Testability ✔ ◦ Well Structured ✔
  13. 14.
  14. 15.

    Model “Types”: Dry it Up! • Decorate Model “Types” ◦

    Maintainable ✔ ◦ Readable ✔ ◦ Reusable ✔ ◦ Testability ✔ ◦ Well Structured ✔
  15. 17.
  16. 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….
  17. 19.

    Model “Types”: CRUD Actions • Decorating our Model “Types” with

    our common CRUD Actions enforces: ◦ Consistency ◦ Readability ◦ Maintainable ◦ Reusability
  18. 20.

    Recap: Model “Types” Pattern • Maintainable ✔ ◦ Structural Design

    Pattern (Facade Pattern) • Readable • Reusable • Testability • Well Structured
  19. 21.

    Recap: Model “Types” Pattern • Maintainable ✔ • Readable ✔

    ◦ Focused Methods/Functions ◦ Intention-Revealing Interfaces • Reusable • Testability • Well Structured
  20. 22.

    Recap: Model “Types” Pattern • Maintainable ✔ • Readable ✔

    • Reusable ✔ ◦ Selectors ◦ Prop Types ◦ CRUD Actions ◦ Spec Examples - Factories • Testability • Well Structured
  21. 23.
  22. 24.

    Thanks, I’m Ryan Haase Software Engineer @ Mavenlink I Love

    Design Patterns and Dogs GitHub: ryandhaase Twitter: @ryandhaase Email: rhaase@mavenlink.com