Talking with a react-redux user earlier this year, I thought I should probably get with the program and learn some sort of state-management framework. I’m posting my notes from getting started with Redux applied to React and Typescript, hopefully so others and my future self can quickly jump into the ECMAscript pot-pourri.
Redux
The react-redux primer provides a gentle introduction to a rather disjointed framework. Honestly, Redux looks like it was extracted from a webapp following good design patterns without much regard to usability on the framework for developers outside the original project.
Redux prescribes a framework to
- use “immutable” application state objects (there’s no enforcement of immutability)
- invoke actions as pure functions to build a new state from a previous state
- store and dispatch actions for agents/components/etc driving state changes and agents/components/subscribing to state changes to respond.
The result compartmentalizes all of your application logic from presentation, making things easy to compose and test, though not necessarily to read. Much of the processing in Redux just building objects to represent state or dispatch and there’s no support from ECMAscript to flag usage errors, so it’s easy for users make mistakes wiring up components or violate “immutability”.
To add to any confusion documentation overloads the word “action” to mean a token describing which action to take, a factory to create the token, and the actual processing action. Combined with React, the term “state” is overloaded, sometimes denoting application state driving Redux, and sometimes the changing qualities of a React component, driving rendering.
Mix in Typescript
With the far-flung objects and files, having some compiler help would seem appreciated. In fact, using Typescript detects a lot of wiring mistakes early, but with several costs, especially since the Redux-with-Typescript introduction is pretty thin.
Experimentation
My experience incrementally adding Typescript to a sample project illuminated several benign mistakes, mostly surrounding polluted types. It’s easy to conflate the React properties of simple React components and those wired for Redux, or just to omit the former and use exclusively the latter — don’t do it!
The benign mistakes are infuriating, since an app made with create-react-app will initially render and run…. and then halt once the Typescript compiler finds an error. The prevalence of these sorts of errors might discourage one from experimenting or refactoring. On the up-side, at least the default set up for unit-tests with Jest is more lax than the app served by react-scripts start.
Versioning
React has gone through so many versions and patterns, it can be difficult to align your usage with documentation and examples… and type definitions! Especially with the onset of React render and useState hooks, and the lag in update to declaration files.
Dealing with Dynamic Types
Redux leverages dynamic typing in ECMAscript to compose state and reducers as well as to decorate/inject React components with actions. The result can be a nightmare of tangled union types for you and the Typescript compiler.
Where the Rubber Meets the Road
Redux builds React component properties with react-redux.connect() a curried function taking two parameters, usually called mapStateToProps and mapDispatchToProps, each functions as well.
Components respond to state changes with mapStateToProps(), which translates the application state to component properties. At minimum, the function should pull out the relevant fields to build some of the property fields for the component. Make sure to forward along only fields relevant to the component, as the Typescript compiler will infer types and throw an error if the JSX instantiating the component is missing the field.
The dual to mapStateToProps() is mapDispatchToProps(), which allows components to forward messages to the reducer for state updates. The property fields that the function builds are methods to which components wire DOM events.
You build a regular/simple React component, which you then pass to connect() which is used by react-redux to build a factory to create connected React components. It’s useful to distinguish simple from connected component classes, especially the property types used by the two:
- You will export the connected components for JSX use. The connected components will likely have simplified properties, probably (hopefully) silently inferred by the Typescript compiler.
- The simple components have all the property fields, which you will explicitly define, many of them actions, used to wire up and respond to DOM events.
Tersely, mapStateToProps() provides property fields used for rendering; mapDispatchToProps() provides property fields that are functions to drive state changes. The union of the two should fill out the simple component property type.
