python script also calls user/-main , do you do the same with cider?

In there there’s ui/start-app! that actually starts the app

Hang on I feel a facepalm coming

there it is

all good 🙃

Here, I extracted user/start from user/-main so you can start app without starting server repl https://github.com/HumbleUI/HumbleUI/commit/7dbc511c012f35ad83399576e1b8dc8c78481e20

🙏

Interesting to see you embracing React patterns. Makes sense given the original goals.

This is just an experiment to see how ergonomic that would be

I'd take hooks over classes (because they compose), and I'd take solidjs signals over hooks

Is there any reason why both models can't be supported by the lower substrate?

I think signals work fine with React model, but then you still have to decide between classes or hooks, both of which are not exactly natural for Clojure

Thanks, no experience with signals (only briefly looked at SolidJs) so I find the evolution and discussion interesting.

Is there a side-by-side comparison of code for classes vs hooks? I'm currently running a Datalevin database with an in-app event system. Whenever a screen begins transition, I reify its required state into HumbleUI's state-atom. In an ideal world, I'd pull data directly from the database inside a (dynamic ...) binding, but I haven't attempted this yet. With a surface level of understanding, I'm inclined to agree with lilactown's hooks > classes, but I'd have to understand what my downstream implementation will look like to provide good feedback.

No comparison for Humble UI but there’re lots for React I think. E.g. https://www.bitovi.com/blog/react-hooks-vs-classes-the-ultimate-comparison

There’s one here too https://overreacted.io/making-setinterval-declarative-with-react-hooks/

Reading through these, I'm reminded of trying an early release of Om Next many years ago. I didn't get far and left with a healthy fear of components, something I'd forgotten until now. I suspect hooks would be a more flexible way to handle reifying state. They seem like a better basis for implementing a closely woven re-frame style dataflow without being caught up in an intermediate layer of components. The functional flavor of HumbleUI's API has also been pleasant to work with & I'd like to retain that as much as possible.

Yeah, Om Next was more complex than it needed to be

I'd believe it. I chatted with a friend on hooks vs components but without a real conclusion. His complaints about hooks were that it breaks symmetry with the code tree, can be hard to debug when they break, & taints code. But that they usually "just work." He viewed components as more simple & self-apparent but not inherently better. The conversation reconvinced me that I still don't know enough to make a useful decision -- but I'll try moving my HumbleUI codebase over to latest HumbleUI main in the coming weeks & see what I learn.