Pluggable JSX layer?

[brodycj]

In general I think this is really awesome work and will do as much as I can (within reason) to promote it.

That said, I suspect it should be possible to take advantage of more widely used JSX processors such as Acorn JSX (https://github.com/RReverser/acorn-jsx) or perhaps Babel transform-react-jsx. More widely used, better documented, etc.

I would be happy to give it a try when I get a chance.

It would also be cool to support something like https://github.com/choojs/hyperx (which can be interpreted or compiled) or adaptation of https://github.com/hyperapp/html API for those who may want a more pure JavaScript API (maybe better for CodePen as well).

[adamhaile]

Yep, replacing the current parser is in the plans, but I want to get 0.5 out first. I already did some of the preparation work to bring the internal AST representation closer to the ESTree standard used by other parsers.

Currently, Surplus relies on ahead-of-time compilation to capture the evaluation of expressions -- the parts between { } -- and make them re-runnable. The source is transformed to wrap them in a lambda, which then becomes an S computation. That's not possible, unfortunately, with a purely runtime strategy. It would require that the user do it by hand. I commented on this about a possible string literal strategy here, if you're curious.

[brodycj]

I commented on this about a possible string literal strategy here

26 for visual reference.

The source is transformed to wrap them in a lambda, which then becomes an S computation.

Makes sense. Seems like this would be an issue if someone would want to use a form of "hyperscript" such as hyperhype / hyperscript, ohanhi / hyperscript-helpers, etc.

I suspect it should be possible to use some kind of special S functions to describe a view with some elements fixed, other elements dynamically changing based on S.data or SArray data elements, always use some form of SArray for map calls, etc. If all parts of the view are described by S functions then maybe no need or less need for additional wrapping. Does this make sense or not?

[luwes]

@brodybits Sinuous kinda explored this route if you're interested https://codesandbox.io/s/sinuous-counters-7m4zy

it does have the drawbacks like @adamhaile explained, the more complex computations need to be wrapped in lambda's and DOM creation is slightly slower. Simple observable (signal) or computation references can still be defined without a lambda because a function reference can be wrapped in a lambda at runtime as well.

At the same time it's more flexible in the view syntax one can use. Tagged templates, JSX or hyperscript calls.