signals VS pullstate

Putting the runic terminology aside and looking into how the signal primitive is implemented should dispel the magic. I learned a lot from examining preact's implementation: https://github.com/preactjs/signals/blob/main/packages/core/...

https://refactoring.guru/design-patterns/observer/typescript/example https://indepth.dev/posts/1269/finding-fine-grained-reactive-programming#how-it-works https://legendapp.com/open-source/legend-state/ https://legendapp.com/open-source/state/fine-grained-reactivity/ https://www.builder.io/blog/usesignal-is-the-future-of-web-frameworks https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf https://medium.com/hackernoon/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254 https://preactjs.com/blog/introducing-signals/ https://hygraph.com/blog/react-memo

All the frameworks are starting to adapt them. You can easily add them to react project as well. https://preactjs.com/blog/introducing-signals/

Signals are a design paradigm for reactive programming which have recently trended in the JS frontend space. For e.g., https://preactjs.com/blog/introducing-signals/

Compare Vue's reactivity system to the principles the Preact authors write about here:

Reactivity libraries are at the heart of modern web component frameworks like Solid, Qwik, Vue, and Svelte. And in some cases you can add fine-grained reactive state management to other libraries like Lit and React. Reactively comes with a decorator for adding reactive properties to any class, as well as prototype integration with Lit. Preact Signals comes with a prototype integration with React. Expect more integrations as these reactivity cores mature.

State solution should not be a framework, this is what I dislike in riverpod as well.. its a FRAMEWORK... compare to the simple useSignal hook that preact has https://preactjs.com/blog/introducing-signals/ this looks like an overkill.

Looks like it's coming from here https://preactjs.com/blog/introducing-signals

Sciter got native (built-in) Signal implementation made after PReact's Signals;

PullState - https://lostpebble.github.io/pullstate/

Pullstate. It's a lot like svelte's store.

And automatically, any components using uiStateStore.useState and watching the isSidebarOpen property will get updated, exactly the same as the normal useState hook - just shared.

It's so dead simple and has made complex app-building so much easier for me.

The one caveat is that if I have a component with many handlers, e.g. onClick, onMouseMove, onContextMenu, onMouseLeave, etc (and in some cases I do), components can get bloated. I haven't found a fix to that yet. But that's more an inherent issue with react than anything to do with state management.

[1] https://github.com/lostpebble/pullstate

Sounds like you're on the right track. React is very hire-able. Try out multiple store systems. The big one is react + redux. Then after you have some experience with that, try a simpler one like pullstate.

You could try out pullstate - its basically just global objects which you can mutate and which automatically update your state over your entire app, for whichever parts you have "pulled" the state into.