React truly revolutionized modern UI development. Instead of imperially mutating
the View based on the newly arrived data, React enables us to declare the View
as a function of state
V = f(state). In React terms, we call those functions
components and thanks to the nature of functions, we are able to compose
them and eventually structure our complex UI as a Tree. Additionally, we can do
neat things such as high order functions on our components (remember, components
are functions!!), react-redux’s
connect is a perfect example.
React claims itself to be a library but not a framework. I agree with this claim
as all it does is providing an unopinionated API so that we can declare our View
as as a function of State. However, it also comes with a state management API
setState which, in my opinion, is an opinionated way of managing the
It is totally feasible to build a relatively complex application without a state management library in React.
Let’s say we are making a task management application. We have a list of users
and each user has a list of tasks. Using the above approach, we will store the
entire state (root state) in the root component. Then, we pass the lists of
tasks along with users to
User components. Afterwards, we pass each individual
task data to
Task components. Task components will be the leaf nodes in our UI
tree in this case.
There are a few problems with this approach. First of all, due to React’s
functional nature, data flows in one direction. The root component needs to pass
mutation functions down to their children. This will result in boilerplate and
obfuscated code. Most importantly, the shape of your state tree has to match
the shape of your UI tree. This constraint makes it difficult to model your
application state. But our state is not always a tree, it is most likely a graph
in real life. As for our task management application, let’s say we want to
introduce an admin user who can delete other users’ tasks. We want to render a
x next to a task if the current signed-in user is an admin. With React’s state
management API, you will end up passing
isAdmin down to every single
The biggest problem Redux (and many Flux libraries) solved is that you can model
your application state tree independently from your UI tree. With
mapStateToProps and selectors, you can
connect a node or multiple nodes of
the state tree to a node on your UI tree. In addition to that, Redux enforces a
few rules which introduces a bunch of boilerplate but makes your app easier to
reason about. To name a few,
Managed mutations: All mutations must be requested and it is applied one at a time. -> consistent
Reducers: New state is produced by a pure factory function. -> Predictable state -> no invalid state.
Immutability-> cool development tools
Redux is cool but it does not provide a solution to handle the data fetching/caching layer. Developers usually have to develop a custom solution. It is pretty fun to check out how different people implement data fetching with React and Redux.
Graphql not only enables us to write descriptive queries but also unlocks the
ability to compose smaller queries (through
fragments). This allows individual
components to declare the data it needs and Relay will automatically aggregate
them into a single query so that we can fetch the data with one single network
request. This seems to be unrelated to the state management problems Redux is
trying to solve. But if you look at it closely, Relay allows us to not declare
our state data tree explicitly. Relay is gonna figure out what does your
state tree look like according to the queries declared by each of your
components. That is pretty neat!
Single page apps make our users happy but our lives hard. I hope you enjoyed my two cents on the React ecosystem in 2017. Currently, I am fiddling with Datomic and om-next. IMO om-next’s query language is much simpler than Graphql (familiar data structure vs a DSL). I am planning to build a side project using those two technologies and hopefully I will be able to write a blog article about them in the near future.