Why Redux is not so easy, some alternatives

React with Redux is probably the most popular front-end framework in this year. Redux is great and has changed architecture of front-end apps. If you are looking for new job, you probably will find some interesting offers with Angular 1.x, Angular 2 and others, but most interesting are about React & Redux.

The choice for a lot of programmers is quite obvious, but we should consider some cons of using Redux:

It’s not easy to switch to work with reducers Don’t Repeat Yourself Care about performance — render()

It’s not easy to switch to work with reducers

You will need to care about functional principles and always return new value based on previous state. Sometimes it’s easy (simple string, objects or array operations) as:

return {…previousObject, newValue: value}

but for more complex changes you probably would like to use Immutable.js or similar library.

During the work on large application you will need to think about combine reducers, higher-order reducers, separate UI and data states, handle errors in your async requests (redux-thunk, redux-promise — libraries for manage async actions) and build some abstract layer (for computations) by eg. reselect library. You need to also remember, that data in your reducer should be normalized and would be better to have those data as flat as possible — check normalizr library.

I recommend gitbook Redux without profanity to check, how author try to solve problems of Redux state management:

Don’t Repeat Yourself (DRY)

Working with Redux needs to keep some conventions, as create actions types, actions (action creators) and reducers.

For similar logic as CRUD operations (synchro with server) your Redux code maybe will look very similar (isLoading state, errors handling, Map() or List() with your data from response etc.). Adding small functionality will need from you adding a lot of redux logic + tests. You will think probably about refactoring to follow DRY rule.

Maybe good choice will be to create something like a abstract layer / API for Redux flow to avoid writing similar code for CRUD operations on your models.

Care about performance — render()

In the end what we really want to have is a single source of truth which is easy in maintain, and which trigger smallest changes in DOM structure as possible.

During work on React application you need to care, that what you pass by props are the new data, because they will rerender whole component. Sometimes you will want to prevent render (by shouldComponentUpdate method) and maybe use pure render mixin to check that data is really changed (you can also use React.PureComponent since React 15.3).

In more complicated data structure Immutable.js library is really helpful, because it operates on references to objects (your store is an Immutable.js tree of references to smaller Immutable.js data). You can imagine situation, when very nested component use small part of your store. You have changed another part of store which is not used directly by your nested component. Immutable.js will prevent unnecessary rendering because component will have reference to the same object in his property.

There are some rules which you need to keep in mind when you work with Immutable.js in React. Those rules are not very obvious for new developer, as do not trigger toJS() method before injecting data to your props. Using Immutable.js in wrong way very often doesn’t give you a lot of benefits. Eg. toJS() method always create new object, so it triggers unnecessary rendering when you pass it by property.

This article is a must to read before you start developing with Immutable.js: