Using SolidJS primitives in a React app

[guillaumebrunerie]

I've been using React and Redux for quite some time, and I have started looking at SolidJS recently. I am not yet really sold on the way rendering works in Solid (I understand it and see some benefits, but I'll probably stick with React for now), however I am really interested in the reactive primitives themselves, that is createSignal, createMemo, createEffect, and createStore, and in particular I am thinking about using them in a React app.

I tried at reduxjs/react-redux#2043 a proof of concept for an alternative implementation of Redux using Solid stores, which leverages reactivity to know exactly which components to rerender instead of having to run every single selector after every dispatched action (like normal Redux). I haven’t tested it in a real app yet, so take it with a big pinch of salt, but in a toy example it seems to work, and I could also relatively easily make things like memoized selectors and debounced selectors in a much easier way than with Redux.

Has anyone else tried to use Solid's primitives inside a React app?
I have also tried to look for other similar state management libraries for React, but for instance Jotai has signals, but nothing like stores, and Valtio has stores, but nothing like signals or createMemo (that I could find), whereas Solid seems to have all that I need.

[snnsnn]

Has anyone else tried to use Solid's primitives inside a React app?

Do you mean like sharing state between React and Solid? If so, you can't, because they have separate runtimes, at least not without performance heavy glue code and state wrappers, then you will have problems compiling componets because both use JSX. Chosing one as the main tool and rendering branches on the main app using the other one is your best option but you already said that you didn't like it.

Try preact, they have a very close signal implementation to Solid's.

https://preactjs.com/guide/v10/signals/

[snnsnn]

I mean using React for everything related to JSX/rendering, but using Solid signals/stores for state management (which do not depend on JSX in any way). And then, to make React reactive to signal/store changes, we can simply use a (Solid) createEffect which calls a (React) setState whenever some dependencies change.

My answer addresses this use case.

If you need solid's like store you can implement one using preact's signals. Solid's store is a proxy wrapper around a signal. That is the best path you can take.

[guillaumebrunerie]

I really don’t see how it is possible to implement a store using signals, except by reimplementing the whole proxy stuff in solid-js/store, which I would guess is highly non-trivial. On the other hand, directly using solid-js/store plus a thin wrapper combining createEffect, useEffect and useState does seem to work just fine in React, at least on a toy example (see here, a very basic todo list example, initially based on Redux but where I replaced all Redux code by code based on solid-js/store). The Solid primitives createEffect, createStore, createSignal, etc. are completely independent from the rendering system and Solid's interpretation of JSX, so there is no reason they wouldn’t work in React. But I guess it’s not very common to use them outside of Solid.

[snnsnn]

How is that possible to have a thin wrapper if you pull in a whole reactive system. You might not see it but VDOM ruins everything, that is why there is redux. It is not that you can not call React's setState via an effect, it always be suboptimal because of VDOM.

I really don’t see how it is possible to implement a store using signals, except by reimplementing the whole proxy stuff in solid-js/store, which I would guess is highly non-trivial.

Why not, it is just a few functions. Half of it server side code. Plus you have the test cases ready. You'll have faster code with smaller bundle size. It will save your time on the long run.

[guillaumebrunerie]

How is that possible to have a thin wrapper if you pull in a whole reactive system. You might not see it but VDOM ruins everything, that is why there is redux. It is not that you can not call React's setState via an effect, it always be suboptimal because of VDOM.

What exactly does the VDOM ruin? Some preliminary tests seemed to show that my very naive implementation was already significantly more performant than Redux on a real life app (because the automatic dependency tracking of stores made it so that some computationally expensive functions didn’t need to run as often).

The VDOM itself is only slow if you have large components or if you rerender components high up in the tree. Using very small components and making sure to rerender only when needed and as low as possible in the tree give you something very similar to fine-grained reactivity à la Solid. Sure the VDOM needs to be kept in memory and rendering/diffing needs to be done, but this is very cheap for small components. Solid gives you fine-grained reactivity for free, but you can already basically get it in React as long as you're very careful about the size of your components and when/why they rerender.

Also I'm not sure what "that is why there is redux" means. Redux relies entirely on React's VDOM and rendering system, it does not attempt to bypass it in any way (unlike "rendering optimizations" in Preact signals). What Redux optimizes is to make sure to only rerender components that really need to rerender. I'm doing the exact same thing with stores, but automatic dependency tracking make it even smarter than what we can do with Redux.

Why not, it is just a few functions. Half of it server side code. Plus you have the test cases ready. You'll have faster code with smaller bundle size. It will save your time on the long run.

Because proxy code is very messy and error prone, you need to implement recursive proxy wrapping, all the various traps for getting a value/setting a value/deleting a value/getting all keys/and probably others that I don’t know about, and I would really rather rely on a well-tested and maintained library instead of writing such code myself.

[snnsnn]

It is not inherently bad, but not a good fit to interface with fine grained reactivity. Redux is there for the very same reason, managing state. Redux was pulled into the core library later, in version 16 something.