Should we do state management directly with yjs, or through bindings like SyncedStore?

I recently read an opinion that it is better to do state management directly with yjs than through some state management library.

CRDT is not (only) a data structure for multi-person collaboration, it already covers the front-end “state management” capabilities itself, including mechanisms such as transaction and batch. From this perspective, there seems to be no clear need for developers of collaborative applications to add another layer of “state management libraries” on top of it, unless it is for compatibility with older projects

Should we do state management directly with yjs, or through bindings like SyncedStore?

What do you think?

It really depends. There are arguably nicer libraries for state management. Yjs is meant to have a minimalistic interface for observing changes (and calculating differences) that can be integrated into other libraries. It doesn’t have the reactive interface of mobx, and isn’t immutable like Redux. There is no big performance loss in integrating Yjs into an existing library. It might be worth it.

SyncedStore is awesome, use it if you like it.

However, nothing is perfect. Most users of state management libraries don’t think too much about properly organizing data for managing conflicts, optimizing shared data for performance, and migrating existing data to new schemas. React data stores are, in my opinion, too close to the representation. You likely want to reorganize data when the structure of your application changes. synced-store might make it too easy to make an existing application collaborative. Instead, you should think very carefully about the schema of your data. Because it’s really hard to change it once you have active users.

2 Likes