Did you try I used it in a project where I was capturing dozen of events. The list is growing and growing and this component helped me render all of them. I'm not sure how Redux Form works but if it is based on mounting then I guess this is a good option.


Existing open-source form libraries seem to not work well when getting into this kind of complexity. We implemented a number of optimisations by building our own form library, but it's possible that one or more of these ideas you may be able to use with redux form.

We mount a multitude of form & other redux attached components (in the order of thousands), which all do validation when they get mounted. Our architecture required all components to be mounted at once. Each component may need to update the state multiple times when they get mounted. This is not quick, but these are the optimisations we used to make this seem quick for 1000+ controls:

  • Each component mounts in a way which checks if it really needs to dispatch something right now, or if it can wait until later. If the value in the state is wrong, or the current value is invalid - it will still cause a dispatch, otherwise it will defer other updates for later (like when the user focuses it).

  • Implemented a batch reducer which can process multiple actions in a single dispatch. This means if a component does need to perform several actions on mount, at most it will only send 1 dispatch message instead of one dispatch per action.

  • Debouncing react re-renders using a redux batch middleware. This means that react will be triggered to render less often when a big redux update is happening. We trigger listeners on the leading and the falling edge of redux updates, which means that react will update on the first dispatch, and every 500-1000ms after that until there are no more updates happening. This improved performance for us a lot, but depending on how your controls work, this can also make it look a bit laggy (see next item for solution)

  • Local control state. Each form control has a local state and responds to user interaction immediately, and will lazily update the redux state when the user tabs out of the control. This makes things seem fast and results in less redux updates. (redux updates are expensive!!)

I'm not sure any of this will help you, and I'm not even sure that the above was smart or recommended - but it worked really well for us and I hope it can give you some ideas.

Also, if you can get away with mounting less components (pagination etc), you definitely should do that instead. We were limited in our choices by some early architecture choices and were forced to press on and this is what we came up with.

Related Query

More Query from same tag