No need for caching support?

[hrachovm]

This is a nice little package, but I am curious why the caching was removed.
I found this change in history b9be5b3
Can I ask what was the reason for it?

[zaceno]

Sorry for the late reply!

The reason I had to remove caching was that hyperapp internally mutates the virtual-nodes during it's patching process, and uses those mutations to keep track of ... something in the patching process. I don't know. I just realized that if I passed the same (cached) virtual-node to hyperapp multiple renders in a row, there would occasionally be strange rendering bugs. So I just decided to take out the caching all together. It's all pretty snappy anyway.

You can use hyperapp's built-in memo() if you need to cache heavy & mostly static components. I have been thinking about integrating memo into hyperlit somehow but not really come up with something that feels right. Think it's best to keep it simple :)

[hrachovm]

Thank you for the answer. I didn't realize the cache was done based on v-nodes. When I was thinking about it I was thinking of transformation of the string literal to another data structure, cache this one, and apply literal values to it to generate the v-nodes using h/text functions.

const todos = ({items}) => jsx`TODOs: <ul foo="bar">${items.map(item => jsx`<li>${item}</li>`)}</ul>`

to something like this

item = ['li', {}, [0]] // zero means first parameter from literal values
todos = ['TODOs', ['ul', {foo:'bar'}, [0]]]

Benefit would be the string parsing is done only once. All the SVX logic including structure validation.
Processing of the once generated nodes hierarchy would be very fast.

Based on your comment but not really come up with something that feels right I guess you have already considered this approach and ruled it out 😄

I have tried to make changes to your code to add this idea to it, but realized your implementation is "happy path based"; no validation at all 😄 The topic was interesting to me enough to give it a try to see how the whole solution would look like. So in a meantime I have implemented the whole stuff. I did my own parsing (heavily inspired by yours) to include validation and then added the caching too. In case you would be interested I placed it here https://github.com/hrachovm/ha-jsxlit/blob/master/jsxlit.js
Please note this is very rough and wip without any guarantee the paring is actually covering the JSX fully. Good enough for my experiments, though.

[zaceno]

Hah yes indeed very "happy path" orientented. Was going for minimalism and thus no hand-holdning. I of course welcome you and others to play around and build on top of it - or something better (it's certainly nothing fancy or impressive - just real basic state-machine-based string parsing). Don't have time at the moment to take a deep look at your approach. Just writing this to say I like where you're going and fully intend to dig in at a later date. (I want to potentially reimplement hyperlit based on a new Idea that might make it more easy to cache, besides fixing some whitespace issues)

[hrachovm]

I've spent some more time on this. Changes are available in the repo (not pushing you, just FYI; whenever/if you feel like looking into it). I started adding descriptive error messages for jsx structure violations and support for "unit" testing.

P.S. basic state-machine-based string parsing 😄 Well, I wouldn't say html parsing with magical newlines handling is basic, but whatever 😉 BTW I am using this live JSX parser on babeljs.io as a reference.