FREDDY RANGEL ▸ Front-End Engineer @ HelloSign ▸ Author of “React Under the Hood: A Beginner’s Guide” and “React: The Good Parts” ▸ Contributor to React ▸ Taught “React Under the Hood”, “React 2016”, “D3 and React” ▸ Google me
SYLLABUS ▸ Module 1: Overview of React, Redux, and Async ▸ Module 2: Redux Crash Course ▸ Module 3: Redux Middleware ▸ Module 4: Async with Thunks and Promises ▸ Module 5: Async with Generators and Sagas
QUESTIONS BEFORE WE START?
LETS REVIEW SOME CLASS STATS
OK LETS GET STARTED
REACT IS NOT YOUR ARCHITECTURE
FLUX PATTERN FOR STATE MANAGEMENT
REDUX IS A GREAT STEP FORWARD
REDUX ▸ Manages state changes via pure functions and a uni-directional data flow ▸ Inspired by the Elm Architecture ▸ When your Redux store state changes, your React views respond with new data. ▸ Removes business logic out of your React views
REDUX IS A WORKFLOW, NOT A COMPLETE ARCHITECTURE
REDUX MIDDLEWARE ▸ A third-party extension point between dispatching an action and the moment it reaches the reducer. ▸ Uses currying to allow you to create custom dispatch functions (middleware) that are called sequentially in between dispatching and the reducer ▸ Essentially, you can hook into the dispatcher with a chain of functions
WHY MIDDLEWARE? ▸ We can keep the ease of debugging with Redux and build on top of that with middleware. ▸ We can use the Redux store to track the state of async operations, but middleware manages operation of async operations.
THREE STATES OF ANY ASYNC OPERATION
THREE STATES OF ANY ASYNC OPERATION ▸ Pending: Operation is in progress. Useful for telling the user to stand by or to keep other requests in sync. ▸ Fulfilled: Operation is finished. Update the UI or do some other operation. ▸ Rejected: Operation failed. Handle the failure in whatever way makes sense for your application.
REDUX THUNK ▸ Normal actions are objects. ▸ redux-thunk allows you to dispatch a function which will be called by redux- thunk middleware. ▸ redux-thunk will pass in dispatcher and getState functions so you can dispatch an action at the end of an async operation
PROS ▸ Very simple abstraction. You can write this yourself without the need of a library. ▸ Fairly easy to test if you run your tests in Node. ▸ Works well for small projects.
CONS ▸ No real dependency injection that isn’t clunky ▸ Not FSA compliant ▸ Unlike promises, it’s too easy to ignore handling pending and error states.
PROMISE MIDDLEWARE ▸ Very similar to thunk middleware ▸ Most redux promise middleware libraries are already FSA compliant. ▸ Promises are in the language and are built for async. ▸ Use pburtchaell/redux-promise-middleware. It’s the best one out there with good conventions.
REDUX-SAGA ▸ A Redux implementation of the Saga Pattern. ▸ Based on generators. ▸ Instead of dispatching Thunks, you create Sagas to gather all your Side Effects logic in a central place. ▸ This means application logic lives in 2 places: ▸ Reducers are responsible for handling state transitions between actions. ▸ Sagas are responsible for orchestrating complex/asynchronous operations.
SAGA PATTERN ▸ Saga is a failure management pattern. ▸ Sagas are multiple workflows, each providing compensating actions for every step of the workflow where it can fail. ▸ You can think of Sagas as daemons, a long living process for orchestrating transactions and handling recovery from failures.
REDUX SAGA ▸ Is showing a lot of promise. ▸ Will see more adoption because it takes async as an important part of your architecture. ▸ Will probably inspire other libraries based on similar ideas like CSP Channels from Go and Clojurescript.