Performance Comparison of State Management Solutions in React

This time I am not going to do deep comparison of State Management Solutions for React because of 2 reasons

• Previously I have made deep overview of State Management Solutions for Angular and instead of ngrx I will include Redux
• There are plenty information about Redux out there

So in this post I am going to compare performance of

• @react-state/store
• Redux
• Akita

Let’s begin 🔥 😎

Same as in previous blog post I have created 3 applications for each of candidates with flowing scenario:

• add 1000 rows to UI per 10 iterations: 1000 operations
• Update 1000 columns 50 times: 50 000 operations

Non of candidates were able to handle such amount of operations without batch updates (@react-state/store), batch renders (Redux) or sampleTime (Akita).

@react-state/store is build on same core and has similar architecture as @ng-state/store. Of course there are plenty changes made for react (like binding to react life-cycle hooks and etc)in order them to work together.

Results:

• Add items: ~0.6s
• Updating items: ~6.5s

It was 50 state mutations sent to Redux DevTools because all operations made inside update function are batched by default in @react-state/store. You can turn it off by passing false as a second property but it is rear cases when you might need it because it does not causes any performance penalties.

You can play with it on:

Redux needs no introduction.

Results:

• Add items: ~0.7s
• Updating items: ~6.2s

I had to install 3td party library redux-batched-subscribe in order to not call render 50k times. With help of this library renders where batched to 51 but It was 50 000 state mutations sent to Redux DevTools.

You can play with it on:

Akita - you can find deep analysis about it on this blog post. I was creating an example based on two sources: Their github react play ground and this blog post.

Short off-topic comment: Inside of their example, they are subscribing to todos query and uses setState to set todo items in order to get them rendered. Guys, do not ever do that ❗️ ❗️ ❗️ Why? Because Akita is global store, which stores your state. When you set it to component state there appears two source of trues. I mean nobody restricts less experienced developer to mutate todos on component level - will those changes be reflected in global state? 💥 😬 NO! Instead assign todos to local variable and use this.forceUpdate(). You can read note from redux regarding this below.

Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.

OK, back to topic 😁

Akita does not support batch updates so only way to not make UI die is to use operators like sampleTime However results were similar to blog post from Angular.

Results:

• Add items: ~1.3s
• Updating items: ~50s

You can play with it on:

Conclusion

We saw, that @react-state/store and Redux had similar results. Akita still have place for improvements in order to work with data intensive operations.

It is up to you which one to choose: Redux with all its pros and cons, power of ImmutableJs and simplicity (@react-state/store) or Akita. However, before jumping on green field project, have clear vision about business requirements, your goals and state management solution capabilities because it will be your back bone 😎

If you enjoy the article, give some claps to motivate ✋✋✋

Follow me on twitter @VPranskunas 👍

By the way have you tried @react-state/store yet?

Here is complete working application

You can find out more in docs

Introduction

and can install it from npm

@react-state/store