New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#249] Use computation expression syntax for HTML #253
Conversation
This is turning into a bigger pain point than I expected. It is forcing us to have Attr - Children - Key - Ref as the order of items in a component. But it would be really counter-intuitive, from a user point of view, to enforce a different order in elements and in components... The best solution I can see right now is to have a function that combines the Key and Ref, and then have the component builder's implementation of |
As it turns out, there's an easier solution to this issue: the key can come before attributes. So we can have a Key - Attr - Ref - Children order, and have the component implementation swap the last two. |
Replace the list-based syntax with a computation expression-based syntax. This enables much better inlining of the rendering (see the corresponding issue #249).
This is done by having the right set of
Combine
methods on the CE builder (for example there's aCombine(Attr, Children)
but noCombine(Children, Attr)
.Unlike elements, component children are rendered inside an Attr named
ChildContent
.lazyComp*
andnavLink
).virtualize
as a computation expression, usinglet!
to pass the item, for example:Bolero/tests/Client/Main.fs
Lines 293 to 302 in 27a0101
concat
.empty
with a functionempty()
so that it can be inlined.text
function.attr.classes
attributes like v0.18- does.attr.classes
as obsolete? It doesn't have much added value compared withattr.``class``
if different class lists aren't merged anymore.