My two apps use them
Introduction
Recently, I often got asked about this question: Which is recommended, valtio or jotai?
For those who are not familiar with them, they are two out of many state management libraries that I developed.
https://github.com/pmndrs/valtio
https://github.com/pmndrs/jotai
Now, from the library perspective, their implementations are very different. However, from the usage perspective, I understand the confusion. Both serve similar functionalities and we don't usually use both in a single app.
It might be valuable if I could explain which to use if I were to develop some apps.
My answer is I would use valtio for data-centric apps and jotai for component-centric apps.
Let's dive in.
Data-centric and component-centric approaches
In the past, I had this tweet, mentioning "React Centric" and "Data Centric". React component centric approach is an internal store, where as data centric approach is an external store.
This is a diagram to show technical differences among @ReactJS libraries for global state which I maintain/develop. I feel like keeping posting this kind of tweets, but every time it's slightly changed.https://t.co/sJAmYrng5V pic.twitter.com/MgVmy9Go5W
— Daishi Kato (@dai_shi) April 11, 2021
In this article, our focus is the columns in the table. (The rows are from a different perspective.)
Here's another tweet with the same idea. It's "state resides at component level (inside react)" vs. "state resides at module level (outside react)".
Here's another more technical matrix of some @ReactJS global state libraries. It doesn't mean to be super accurate, but to grasp their major characteristics.@Excalidraw shareable link: https://t.co/9P4hsf0gtm pic.twitter.com/OHEXELze4k
— Daishi Kato (@dai_shi) December 25, 2020
Again, our focus is the columns in the table.
So, what are the two approaches?
The data-centric approach is you have data first regardless of React components. React components are used to represent those data. For example, in game development, it's likely that you may have game state in advance to design components. You don't want these data to be controlled by React lifecycle.
On the other hand, with the component-centric approach, you would design components first. Some states can be locally defined in components with useState. Other states will be shared across components. For example, in a GUI intensive app, you want to control UI parts in sync, but they are far away in the component tree.
Note that this is not a ground rule. We could store game state in the component-centric libraries, and UI state in the data-centric libraries. Each library has its own features, so that would be the point of choice.
I would choose valtio for data-centric apps and jotai for component-centric apps.
Let's see the actual examples.
My apps with valtio and jotai
There are two apps I developed each with valtio and jotai.
The first app is called Remote Faces and it uses valtio. It's an app to share your face image with your colleagues to show presense in a remote-work environment.
It has data to be shared with other users. The latest version uses valtio-yjs to sync data with others.
See the GitHub repo for more details:
https://github.com/dai-shi/remote-faces
The second app is called Katachidraw and it uses jotai. This is an SVG-based drawing app.
https://katachidraw.vercel.app
It's actually developed to demonstrate how jotai can extensively used.
The source code is available:
https://github.com/dai-shi/katachidraw
You can also learn the basics in this egghead course.
Summary
It's really hard to suggest which libraries to use in general. The real recommendation is to learn both and understand them.
If data-centric approach vs. component-centric approach discussion makes sense, it may help you to choose one. But still, other features in valtio and jotai are very different. So, you want to at least read their README files.
Another suggestion is, if you really like the syntax of valtio, pick valtio, otherwise pick jotai. If you are even unsure about it, just pick jotai which has less gotchas.
I didn't discuss other libraries in this article. It will be more complicated to compare three or more libraries. Maybe another pair of libraries would be possible to discuss.
Originally published at https://blog.axlight.com on January 30, 2022.
Top comments (0)