Components implementation

[therustmonk]

This is the first draft of components implementation. It breaks backward-compatibility and nominated to 0.3 version.

For demonstration I created example with 1'000 components which work independently. I broke contexts and services (because isolated loop of App used for every component), but I'll repair them.

[rivertam]

Am I mistaken or are props and state both represented by the component struct's properties? What happens if a prop changes both as state and as a prop (from the inside and from the outside)?

[machineloop]

Thanks @deniskolodin, this is great! I also have some similar questions about props vs state, how they're treated within a component. Right now it seems they're one and same, wondering if it might we worth separating them into two models or separate structs, one internally managed per component, one externally provided, much like React. But perhaps I'm missing something that works better in the Elm model...

[therustmonk]

This PR still experimental and I will improve ergonomics of API. Also I want to add properties and events. Apparently it will not fields of the model, but I haven't chosen the implementation yet. I continue to experiment.

[machineloop]

Thanks @deniskolodin, great to see your experimental work so far, let us know if there's anything we can do to help

[machineloop]

I've been playing with your latest commits, thanks for your hard work! One thing I've noticed is when I render a component, it's getting wrapped in a <div></div> by default. This probably works in 90% of cases, but sometimes gets in the way of using semantic and/or properly formed html.

Here's an example: I'm using a component to generate table rows, and the div tags wrap each row, preventing the table from rendering correctly:

Thanks again for all the time you're putting into Yew, I'm excited to see the components API coming together!

[rivertam]

What is the purpose of having routine start as a noop, as opposed to defining it at the top?

[therustmonk]

Just a tradition to pass no-use-before-define lint. Is it safe to take advantage of var behaviour when everything actually defines at top? Will it work in the future? I saw that let doesn't work this way. What do you think?

[keeslinp]

Having two functions that call each other can get a little hairy. Is there a reason that schedule_routine is a different function? My immediate thoughts on this are that you could just inline that function and avoid the two functions referencing each other. Alternatively, the schedule_routine function can take routine as an argument, if you want it to be a general purpose utility to avoid code reuse. Another options is to pull the if block that calls schedule_routine into another funciton that is put into the setTimeout, so it would be something like:

...
task = setTimeout(() => {
    routine();
    if (pool.length > 0) {
        schedule_routine();
    }
});
...

[therustmonk]

@machineloop Thank you for the review! You are right, enclosing <div> is wrong thing. It's a temporary solution, because vdom node expected an element for rendering now. I plan to fix it later when I will implement fragments #36. I tend to merge this PR soon, because it's huge and becomes harder to update ) Also I've tested all features of it and them work well. A few things I'll fix in the next PRs:

• Remove enclosing <div>
• Add Render trait (to unify render function declaration)
• Allow Component to have child nodes through macro (and put children to component's Scope that makes possible to have components composition)

[machineloop]

Thanks @deniskolodin, great work, looking forward to the next steps after merge!

[therustmonk]

This PR is ready to merge. I've tested components and them work fine 🎉 Still need to fix some imperfections after merging (remove redundant enclosing <div>). But this PR is too large to implement it here.