Yet another builder API (and other bikeshedding)

[tamasfe]

Hi, I'm not a huge fan of DSL macros in Rust so I've been experimenting building the DOM with builders as well.

I've just noticed that work is being done in #257 as I'm writing this, but it's reassuring that both of us went in very similar directions.

The key differences I've noticed or I've additionally done in this PR:

• I renamed the existing Component type to RenderFn and introduced a Component trait, as there are some issues with simply treating functions as components:
  • there's no way to attach metadata (like name) to them
  • Rust complains about the naming convention violation, it's possible to bypass this obviously but it's still annoying
• I intentionally kept my ElementBuilder simple and generic, and would rather create wrapper components (e.g. Div) over them with more detailed APIs.
• Blanket impl over arrays of VNodes that turn into a fragment.

As I was poking around the codebase I've also noticed that tag names/attributes are currently required to be 'static, which means it's impossible to create these dynamically without hacks, was this done deliberately as a design decision?

I don't intend to get this merged in any shape or form, I've just done this for the sake of experiments and bikeshedding.

[jkelleyrtp]

Thanks for this!

I still am not terribly happy with the syntax in #257 and it's been crushed by merge conflicts up to this point :-)

It's great to have your implementation.

I've been thinking we might be able to extend Scope via a third party trait so instead of cx.render(dom(move |f| f.element we could do something like cx.element. Not sure if you have any thoughts on ways to make things a little bit more expressive.

I've been really going back-and-forth on whether or not we need 100% type safety vs a simpler API. They tend to fight each other, and while type-safety is easy to achieve with macros, it's challenging when hand-writing trees with regular code.

As I was poking around the codebase I've also noticed that tag names/attributes are currently required to be 'static, which means it's impossible to create these dynamically without hacks, was this done deliberately as a design decision?

This is mostly meant as an optimization so that comparisons of element names are always cheap. However, we don't have checks yet that do ptr comparisons, so it's not really doing much anyways.

[jkelleyrtp]

I'm going to close this for now but feel free to open it up again and rebase it if you feel like.

I'm going to see if we can take some of these ideas for the NodeBuilder work.

Thanks!