Redux for Maintainable Sites

Slides for my lightning talk at the AWeber open house on Thur., Nov 10, 2016. Here I give a quick overview of Redux, what the stack kind of looked like before moving to it, some pros and cons of the technology, and lastly some bonus material on some ideas I've been thinking about with regard to making complex actions more pure to work with.

Transcript

1. React for Responsive Sites
2. React for Responsive Sites Redux Maintainable
3. Jim Fitzpatrick Sr. Software Engineer github.com/jimf @fitzpatrick_j
4. How we got here
5. How we got here • Had an untestable*, unmaintainable* monolith • Began transition to SOA / microservices • Broke up UI into multiple SPAs ◦ Inital SPAs implemented with homebrew MVC ◦ Moved to Backbone
6. Backbone pain points • Tight coupling between views and behavior ◦ Difficult to pivot • Event spaghetti ◦ Difficult to maintain • Difficult to make reusable views
7. Redux
8. Redux is... “A predictable state container for JS apps.” • An evolution of Flux • Uni-directional data flow • Heavily influenced by Elm and functional programming
9. Redux in a nutshell: the store • Global state tree for a Redux app • Single source of truth for all UI and data state
10. Redux in a nutshell: actions • State can only be changed by emitting actions • Actions describe what happened
11. Redux in a nutshell: reducers • Reducers specify how state is updated, given a current state and an action
12. Redux pros (from my perspective) • Every aspect of the application is segregated ◦ State, actions, rendering logic, etc. • Rendering becomes a function from state to UI ◦ Actual rendering engine is an implementation detail • Core components are pure functions • Actions tell a story • Middleware for extension and customization • Amazing community / developer tooling
13. Redux pros (from my perspective) • Every aspect of the application is segregated ◦ State, actions, rendering logic, etc. • Rendering becomes a function from state to UI ◦ Actual rendering engine is an implementation detail • Core components are pure functions • Actions tell a story • Middleware for extension and customization • Amazing community / developer tooling
14. Redux pros (from my perspective) • Every aspect of the application is segregated ◦ State, actions, rendering logic, etc. • Rendering becomes a function from state to UI ◦ Actual rendering engine is an implementation detail • Core components are pure functions • Actions tell a story • Middleware for extension and customization • Amazing community / developer tooling
15. Redux pros (from my perspective) • Every aspect of the application is segregated ◦ State, actions, rendering logic, etc. • Rendering becomes a function from state to UI ◦ Actual rendering engine is an implementation detail • Core components are pure functions • Actions tell a story • Middleware for extension and customization • Amazing community / developer tooling
16. Redux pros (from my perspective) • Every aspect of the application is segregated ◦ State, actions, rendering logic, etc. • Rendering becomes a function from state to UI ◦ Actual rendering engine is an implementation detail • Core components are pure functions • Actions tell a story • Middleware for extension and customization • Amazing community / developer tooling
17. Redux pros (from my perspective) • Every aspect of the application is segregated ◦ State, actions, rendering logic, etc. • Rendering becomes a function from state to UI ◦ Actual rendering engine is an implementation detail • Core components are pure functions • Actions tell a story • Middleware for extension and customization • Amazing community / developer tooling
18. Redux cons • Prone to boilerplate / verbosity • Non-fractal • Generally requires ancillary libraries • Requires some learning
19. Redux cons • Prone to boilerplate / verbosity • Non-fractal • Generally requires ancillary libraries • Requires some learning
20. Redux cons • Prone to boilerplate / verbosity • Non-fractal • Generally requires ancillary libraries • Requires some learning
21. Redux cons • Prone to boilerplate / verbosity • Non-fractal • Generally requires ancillary libraries • Requires some learning
22. Bonus
23. Classes of actions are finite.
24. Do they really need a turing-complete solution?
25. What if ALL actions were just data?
26. Can we offload effects to middleware and work in a smaller language?
27. WARNING: Experiments ahead
28. store.dispatch(Action({ type: INCREMENT }))
29. store.dispatch( Series([ Action({ type: DO_SOMETHING }), Action({ type: DO_SOMETHING_ELSE }) ]) )
30. store.dispatch( Payload( Const(10), Action({ type: INCREMENT_BY }) ) )
31. store.dispatch( Payload( Select(defaultStepSelector), Action({ type: INCREMENT_BY }) ) )
32. store.dispatch( Payload( Future(Const(getAllUsers)) Action({ type: FETCH_USERS }) ) )
33. store.dispatch( Payload( Future( Compose( Const(saveUserById) Select(currentUserSelector) ) ), Action({ type: SAVE_USER }) ) )
34. Gains: Trivialized testing and elimination of entire classes of bugs.
35. Thanks! @fitzpatrick_j