Fork me on GitHub
Roman Liutikov11:02:24

Has anyone played more or less seriously with SolidJS? I spent some time recently learning it a bit more. The model of reactive primitives and tracking is quite similar to Reagent's reactions, I'd say. It's definitely a simplification over React Hooks, but a downside for me is that this granular reactivity requires more effort from a developer. The API surface is also quite large I'd say, just to account for all possible use cases for consuming reactions.

Roman Liutikov16:02:25

I had to do it: It's not clear yet how well Solid integrates with cljs, especially with immutable data, but so far so good

👀 2

@kloud and I were playing with it over in #C036055HWCS awhile ago


Hi Will, I saw you've been working on flex, that's basically solid's signals in pure cljc, right? Pretty cool stuff!

Roman Liutikov20:02:38

Oh, too bad I didn’t know about that channel :(

Roman Liutikov20:02:38

@kloud how’s it going? The name suggests you are THAT Jakub :)


Hi @U0FR82FU1, yup nice to see you again. There are still some open questions left, curious what you come up with in your experiments.

Roman Liutikov20:02:40

I guess the hard part is granular reactivity and Clojure’s data structures?


That is one part, I think wrapping it and doing reconciliation similar to how solid does it with createStore should be fairly convenient for developer, there is some perf cost, but should be still decently performant.

👍 2
Roman Liutikov20:02:56

I haven’t spent much time with Solid yet, so far it feels weird to me, granular reactivity requires additional effort from a developer and I’m not sure I’m willing to take it, being spoiled by react :/


The other part is rendering. One approach is hyperscript, which is pretty straigforward similar to React's createElement wrappers. But that is leaving a lot of performance on the table.

Roman Liutikov20:02:46

I’m curious how much of a difference it is between vanilla Solid and hypescript one for example? Immutable data should contribute to perf as well


Lot of solid's performance comes from the JSX compilation. Unfortunately, that can't be just wrapped reused and wrapped in clojurescript. It should be possible to re-implement via macros, but that would need extra effort. One cool option is using with Squint which can generate JSX and can be processed by standard JS tooling.

Roman Liutikov20:02:59

Oh, for reconciliation, according to the docs it actually diffs data, is that correct? How would that work with non native JS data structures?

Roman Liutikov20:02:58

I guess what you are saying about JSX compiler is that performance in Solid depends on a level of granularity at which it wraps signals? ie the more dom stuff is wrapped in a function, the more expensive rendering is gonna be, because everything in a function will rerun


I believe when it reconciles it just compares references, which should work well with maps.

Roman Liutikov20:02:04

The signals model reminds me of Reagents reactions btw, I guess they are all similar in a way, MobX for example falls in the same category


The JSX compiler hoists the static parts and concatenates them in a string template, then just clones the node which is super fast. In the you can see the output, it is pretty clever how it is done.


Exactly, both are reactivity systems. One can subscribe to solid's signals in react with hooks, or the other way around one can subscribe to re-frame/ratoms from solid components.

Roman Liutikov20:02:50

The template part is interesting indeed


That's the benefit of the fine-grained reactivity, since it does not need to do diffs like react, it can create the DOM once and then just make updates to the "holes".


Yeah, is my take on a clojure-first reactive signal library. Similar to reagent, it relies on dereference to subscribe rather than trapping access to keys


I think the novel thing about solid is the compilation of JSX into updates. I have another library, that I'm experimenting with that and combining it with flex. still WIP

🙌 4

Looks like a neat combo!


Since it has no vdom how does it behave when items in a list are re-ordered? Does it re-render them like non-keyed approaches?


you can attach keys to elements, but I'm not sure how it actually works since it doesn't keep a VDOM in memory


it might just store the info on the DOM node


the real open question I have rn is how to do error handling... since incremental-dom mutates elements directly as you run your patch, if you have error in your logic that throws an exception, you end up in a partial updated state which is not good


Perhaps just nuke the DOM 🙂 Paired with error boundaries to isolate to parts of the subtree and to render error states it might work ok in practice.


it's a little harder to do that with incremental dom


it's an interesting problem, I'm going to keep playing with it. I want to investigate how solid works more and maybe that's a better way to go 😄

👍 2