Redux module patterns
app state, view state and regional state
separating components and containers
and code-splitting reducers
This document details some tips and tricks for creating redux containers. Specifically, this document is looking at the
mapDispatchToProps argument of the
connect function from [react-redux][react-redux]. There are many ways to write the same thing in redux. This gist covers the various forms that
mapDispatchToProps can take.
The React community is moving away from HOC (higher order components) in favor of render prop components (RPC). For the most part, HOC and render prop components solve the same problem. However, render prop components provide are gaining popularity because they are more declarative and flexible than an HOC.
Many people who work with React are familiar with the excellent
classnames library. If you aren't familiar, it provides a simple function for gluing classnames together. In web programming in general, there are many times that we need to add or remove multiple classes based on conditional logic. The classnames library makes this easy.
More and more developers are embracing CSS Next and the power of CSS modules. However, when you add CSS modules to your react components, working with classnames gets more difficult. Typically, CSS modules is implemented with class name mangling. Transforming human readable class name strings into unique identifiers helps ensure that every class name in your app is unique.
This means that you can write your component CSS in isolation without worrying about the dreaded class name collisions that have plagued CSS
A redux app is a chicken and egg problem. Given a particular state, the app should render a certain thing. But... where does that state come from?
Given a blank state, the app needs to rely on the URL to fetch the right data to populate the state.
In a server-side app, the initial state is determined in exactly this way. Given the initial URL, populate the state, render the app, send it to the client.
In a client-side app the situation is exactly the same, except it's totally different. On the client you have way more contextual information than just the URL. Given the URL, the current app state, a components own props and its internal state... a component must decide which data it needs loaded.
There is no "right" way to do anything. Any best practice exists because it's been found by someone to be better than what they were doing before. Often there's a reason that one way is better... but no way is the perfect way. Everything has pitfalls.
If you've been working on a codebase — any code base — for more than a year, you have likely run into a few pitfalls. The decisions we make today have downstream consequences. It's difficult for young developers to tease out which choices will cause big problems in the future. It's difficult for seasoned developers to distinguish between how they usually do it and "the best way".
Best practices change all the time. Like any other type of technology, people are constantly finding ways to improve code. It can be a full time job keeping up with new developments... and emerging best practice don't always stick around. Anyone invested in the early days of ES6 may remember the hype around decorators. At the time they we
Many of the core concepts of react and redux can be found in other application frameworks like Angular and Ember. Classical (class based) frameworks like Ember provide a "kitchen sink" style API -- a prescriptive approach. Redux preaches a functional programming style, where composition and convention are preferred. This leads to a much smaller API but leaves a lot up to the developer.
This lack of a prescriptive API is freeing, but can lead to confusion when constructing your apps. It's up to the individual developer to follow best practices for separating concerns. The good
Our applications have grown organically and our current collection of actions, reducers and selectors are due for an upgrade. This document is an attempt to outline an better way to organize our redux code.
The biggest changes here are the introduction of "modules" and redux-sagas.