The Signals proposal

[loganvolkers]

There is a proposal for standardizing some reactivity primitives directly into JavaScript, similar to the process that Promise went through.

I wanted to share this with the community. As I've been working with multiple frameworks and state management libraries, the need for a standard has become clear.

Case in point was my recent discovery of Zag.js. It makes use of proxy-compare and reuses core concepts from xState. It's a great library, but it doesn't have a jotai, xState adapter, valtio adapter or other state connectors... So using it requires writing an adapter or using framework code to bridge the gap.

It would be ideal if state libraries could have a common interface for interoperating. The signals proposal lays out the case for standardizing clearly.

Here are the questions for the jotai community:

1) Can one of the signals be converted into an atom?

I think the answer here is yes. Jotai's unique strength is its list of integrations with other state management tools. With onMount and writable derived atoms, I think this should be easy to accomplish regardless of what the final proposal looks like.

2) Can an atom be turned into a signal?

Probably, but you would need to specify a store. The default jotai store would work most of the time.

3) Has @dai-shi been consulted on this project?

As a key contributor behind a number of large successful state management tools, his feedback should be sought out and incorporated into the signals proposal.

4) What would the jotai community like to see added or changed in this proposal?

The most logical one IMHO is allowing for the creation of "writeable computed". The current proposal only allows for read-only computed. This seems like it's missing out on the great power of atoms, and the magic of jotai's wrappers of other state libraries. For example taking an atom and changing its internals so that it now stores to local storage or writes to a Zustand store.

[DavidJFelix]

Sidenote:

IIRC, zag.js vendored/copied source from valtio and xstate code into their own codebase in an effort to reduce dependencies and issues for their consumers who might use those libraries while trimming them down to just the parts they needed.

Source:
https://github.com/chakra-ui/zag/blob/main/packages/store/src/proxy.ts#L1
https://github.com/chakra-ui/zag/blob/main/packages/core/README.md?plain=1#L3

[dai-shi]

I wish they could use valtio as a dependency.

[loganvolkers]

At least proxy-compare is still used 🤷‍♂️

[dai-shi]

https://github.com/proposal-signals/proposal-signals

I haven't read it fully, but mostly understandable.

It might fit with Valtio, at least conceptually, but there might be some mismatches. Needs more investigation and experiment.

For Jotai, it's a tough one. While signals represent data, atoms are definitions. atom+store represents data. It might be impossible or very tricky to make signals and atoms interoperable. Also, one big effort in Jotai is async atoms. (Otherwise, the implementation would be much simpler.)

[loganvolkers]

I can see value on having a layer that combines store and atom, but keeps them separate for advanced use cases that might need them.

Most projects that use jotai probably never need to use more than 1 store.

[dai-shi]

Most projects that use jotai probably never need to use more than 1 store.

True, but only on the client side. (Server generally don't have state though.)