Making elements tightly coupled to HTML and promoting components as more idiomatic for custom backends

[lukechu10]

So far, the GenericNode system is completely independent of any web APIs. As the name indicates, it completely abstracts away from the underlying UI node implementation (such as the DOM when running in the browser, or virtual nodes for SSR). The intent of this was to ultimately allow creating custom rendering backends, such as native or TUI or anything the community can come up with.

However, the problem is that the DOM works quite differently from other potential rendering backends. For one thing, because everything ultimately ends up in JS-land, a lot of things are stringly-typed such as element names, attributes, event names, prop names. Some things such as dangerously_set_inner_html are very web-specific and don't have anything corresponding in other rendering backends. Other things such as the distinction between attribute and prop probably don't have much meaning elsewhere either.

As part of the effort to increase type-safety when using view! (e.g. #553 or #354), I have discovered that we need more and more workarounds and generic type trickery so that these type-checked web APIs fit in with the GenericNode trait without pulling in any web specific things into GenericNode itself.

My proposal is to make elements tightly coupled to HTML, in other words, hard-code HTML into view elements. This will allow features such as adding different HTML lints into the view macro, nicer error messages, potentially removing the generic <G: Html> bound that is currently on every component, among other quality of life changes.

As for custom rendering backends, I propose promoting components as more idiomatic so that elements become completely web-specific and components completely backend-agnostic. Consider for example a hypothetical GL renderer for Sycamore:

// Old
view! {
    ambientLight {}
    mesh(scale=..., on:click=|_| {...}) {}
}

// New
view! {
    AmbientLight {}
    Mesh(scale=..., on:click=|_| {...}) {}
}

[arctic-hen7]

How would on:click=|_| { .. } be handled in a backend-agnostic component?

[lukechu10]

How would on:click=|_| { .. } be handled in a backend-agnostic component?

There shouldn't be any problem as far as I am concerned. I don't really see how it's possible to have a backend-agnostic component attach an event handler since that is completely backend-dependent.

[arctic-hen7]

Right, perhaps I'm misunderstanding how this is done currently. If one were to create an alternate backend, how would one manage events now? How would this change with this update?