Async in Redux Workshop: Module 1

Transcript

1. LOGISTICS ▸ Clone and follow README ▸ https://github.com/freddyrangel/async-in-redux-workshop ▸ Follow instructions ▸ Wifi: ▸ Holiday Inn Conf ▸ Code: FWD17 ▸ Coffee / Lunch ▸ Bathrooms
2. ASYNC REDUX WORKSHOP
3. FREDDY RANGEL ▸ Senior Front-End Engineer @ HelloSign ▸ Author of “React Under the Hood: A Beginner’s Guide” and “Hacking the Front End Interview” ▸ Contributor to React and Redux ▸ Google me / Twitter: @frangel85
4. LOGISTICS ▸ Clone and follow README ▸ https://github.com/freddyrangel/async-in-redux-workshop ▸ Follow instructions ▸ Wifi: ▸ Holiday Inn Conf ▸ Code: FWD17 ▸ Coffee / Lunch ▸ Bathrooms
5. 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
6. QUESTIONS BEFORE WE START?
7. JAVASCRIPT REVOLUTION
8. REACT WON IN THE UI
9. REACT WON. DOES THAT MEAN WE SHOULD BE REACT DEVS? ▸ Don’t build “React apps” — it should only be part of your architecture ▸ Separate concerns — React should just be your view layer ▸ Keep your core business logic outside of React components
10. REACT IS NOT YOUR ARCHITECTURE
11. FLUX PATTERN FOR STATE MANAGEMENT
12. REDUX MOSTLY WON AS A STATE CONTAINER
13. REDUX: PROS ▸ Manages state changes via pure functions and a uni-directional data flow ▸ When your Redux store state changes, your React views respond with new data ▸ Removes business logic out of your React views ▸ Your UI becomes a state machine
14. REDUX: CONS ▸ Redux is a workflow, not a complete architecture ▸ Doesn’t have an out of the box async story ▸ You need to build an architecture on top of Redux to handle async ▸ Good news is, Redux has a way to be extended
15. THINGS TO KEEP IN MIND ABOUT ASYNC
16. 3 MINIMUM 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
17. OTHER STATES YOU MIGHT CARE ABOUT ▸ Unstarted: Operation is going to start at some point. Useful for conditional logic in other async operations ▸ Cancelled: Operation cancelled for whatever reason
18. ASYNC IN REDUX?
19. 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
25. WHY MIDDLEWARE?
26. 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.
27. THUNK MIDDLEWARE
28. 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
32. 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.
33. 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. ▸ No way to cancel a thunk
34. PROMISE MIDDLEWARE
35. 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.
36. RXJS
37. RXJS ▸ Reactive extensions for JavaScript. ▸ If Function Reactive Programing (FRP) is your thing, this is the library for you. ▸ It’s a good abstraction, but it doesn’t feel like it belongs in JavaScript. ▸ DSL is huge and confusing. ▸ Many really smart people love it so form your own opinion. ▸ However, don’t use with Redux.
38. REDUX-SAGA
39. REDUX-SAGA ▸ A Redux implementation of the Saga Pattern. ▸ Based on generators. ▸ That we’ve been using at HelloSign in production. ▸ 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.
40. 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.
41. REDUX SAGA: PROS ▸ Takes async as an important part of your architecture. ▸ Turns your async code almost into a reducer ▸ You can find all your async code in one place ▸ Can cancel an async action ▸ Harder to ignore the handling of async states ▸ Because it’s generator based, you can write async code that looks like regular code ▸ No dependency injection or mocking/stubbing needed for testing
42. REDUX SAGA: CONS ▸ Generators can be hard to understand if you’re new to them ▸ Harder to write this middleware yourself ▸ If you’re targeting older browsers you’ll need a generator runtime
44. LET’S TAKE A LOOK AT OUR PROJECT APP