refactor element spec... maybe...

[limikael]

Currently, apx! macro:

<hello prop1="val"/>

Is syntactic sugar for:

Element::create(hello,Props_hello{prop1: "val"})

This more or less forces the use of the macro, because the code without the macro looks very ugly. As an alternative, instead of having elements just be functions that take props, they can actually be part of the struct. The way to define an element would then be slightly different. Instead of:

struct MyElement {
    pub prop1: String    
} 

#[function_component]
fn my_element(p:MyElement, c:Elements)->Elements {
}

... it would be ...

#[component]
struct MyElement {
    pub prop1: String    
}

impl Component for MyElement {
    fn render(p:Self) {
    }
}

Then, the #[component] macro could actually create a builder. Also it would add the children prop to the struct. (for this reason it cannot be a derive macro, since derive macros cannot modify the struct or add to it). It would now be possible to write:

MyElement::new().prop1("hello")

And if it takes children:

MyElement::new().prop1("hello").children(/*...*/)

And then the XML would just be syntactic sugar for the above.

Advantages:

• It is possible to create components without XML.
• The documentation will look a bit better, since now the props struct and function ends up being documented as separate things.

Disadvantages:

• The components are still function components. They are not instances, state information is still managed with use_state, etc. However, if the render function is part of a struct, it kind of makes them look like React class components, even though they are not. This might be confusing.

[limikael]

https://stackoverflow.com/questions/46620790/how-to-call-a-method-that-consumes-self-on-a-boxed-trait-object

[limikael]

I went ahead and did it...

the signature of the render function is render(self:Box<Self>)->Elements which seems to work...

Here is an example without XML:

https://github.com/limikael/appy/blob/master/examples/noxml/src/main.rs