The Signals proposal #2475
Replies: 2 comments 4 replies
-
Sidenote: IIRC, Source: |
Beta Was this translation helpful? Give feedback.
-
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.) |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions