react

orestis 2024-11-18T16:06:50.376199Z

I was looking into migrating our large hx codebase to Helix or UIx. I faintly remember @lilactown saying that implementing hiccup parsing could be done in a custom macro, and that was left as an exercise for the reader. Well, I failed at my first attempt 😄

orestis 2024-11-18T16:08:11.575919Z

Of course, I realise I don't need really to migrate our existing codebase at all. Hx should work fine alongside UIx and Helix, as everything creates plain React components. But it would be nice to be able to use the linters etc without rewriting all of our components.

orestis 2024-11-18T16:09:59.624069Z

Essentially I don't want to have to deal with React 19's breaking changes - I would need to update hx to use the new JSX transform, ref as a prop etc etc. So I was looking to swap out the implementation details of hx with one of the more contemporary libraries that seem to have a bit more corporate support...

lilactown 2024-11-18T18:12:35.085169Z

you probably won't be able to get all of the semantics hx has in macro-land

lilactown 2024-11-18T18:12:53.105159Z

you'll need some kind of runtime parsing

orestis 2024-11-18T18:17:52.876279Z

Yeah, that’s ok. I want to preserve support for hiccup so essentially components created with hx will always try to parse hiccup at runtime. But perhaps I could get fast refresh and linting of props and whatever other niceties you have added ;)

orestis 2024-11-18T18:50:29.438289Z

It would be nice if UIx and Helix were able to be mixed and matched, and accept props as CLJS maps. It seems like I can fool UIx into thinking a component was created by UIx by setting .-uix-component? in the React component. Not sure if Helix has something similar.

lilactown 2024-11-19T05:58:06.062809Z

helix doesn't do any coercion of prop values, only coercing the map to an object with the same keys and values