Features expected for 1.0 version

[andreytkachenko]

Hello, recently I have played with this framework and find it very interesting. I would be happy to use it. But right now it is not ready for real usage and here I'll will try to summarize all key features (fixes) expected for release version of the library.

1. Collections of Renderable of different type

Currently trait Renderable depends on component, but it is a huge limitation not allowing to create a collection of different kind of components and also not allowing to create nested components (Issue #128) (create container components like Tabs, Stacks, etc.), so ideally Renderable trait should looks like:

pub trait Renderable<CTX> {
    /// Called by rendering loop.
    fn view(&self) -> Html<CTX>;
}

Why is it possible?

Component is required only(AFAIK) for handling listeners (precisly for handle result type from listener callback) and for handling props changes. Those two things may be done in the component itself rather then in the library (or some how another way).

2. React syntax

A lot of people got used to use React syntax, and this library has to keep close to it as much as possible, so here is as example:

...
    fn view(&self) -> Html<CTX, Self> {
        html! {
            <div class="barrier",>
                <p>{ format!("{} on {} clicked", self.counter, self.limit) }</p>
                <Button: onsignal=|_| Msg::ChildClicked, title="Middle", />
            </div>
        }
    }
...

should looks like:

...
    fn view(&self) -> Html<CTX, Self> {
        html! {
            <div class="barrier">
                <p>{self.counter} on {self.limit} clicked</p>
                <misc::Button onsignal={|_| Msg::ChildClicked}>
                   Middle
                </misc::Button>
            </div>
        }
    }
...

Reacts componentDidMount analog

I think it will be good to exted Renderable trait:

pub trait Renderable<CTX> {
    /// Called by rendering loop.
    fn view(&self) -> Html<CTX>; // What about to rename this method to `render`
    /// Called after component mounted (updated) with all captured refs HashMap
    fn mount(&self, refs: HashMap<String, &Html<CTX>>) { // Or similar
        /// No default implementation
    }
}

Get rid of all confusing commas and semicolons

here are the issues #98, #127
I suspect it may be solved by a compiller plugin (as @deniskolodin mentioned in #127).

Allow raw text nodes

I don't see any limitations from rust to make it

html! {
    <p> Some raw text here</p>
    <p>{"Regular expression style if you need     special    formatting! Or smiles :)"}</p>
}

Components should be able to have a body

html! {
    <Tabs>
        <Tab>
            Some data here
        </Tab>
        ...
    </Tabs>
}

React's references to elements (virtual nodes)

html! {
   <div>
        <div ref="inner-data">Some data</div>
    </div>
}

3. Move virtual dom part into seporate crate

Why?

Because it would be great to use such react's style with different backends, like stdweb (for web) or GTK (for desktop). I suppose #108 may be easily solved by HTML rendering backend.

Yeah these features will make it actually usable for a serious project. Right now I can only do some small applications. Also something like high order components/render props/children like react would be good so that we can make more parts of the app declarative.
Right now parceljs supports rust and I'm planning to use rust for calculations on state and later on move to this ui framework if possible.
https://medium.com/@devongovett/parcel-v1-5-0-released-source-maps-webassembly-rust-and-more-3a6385e43b95

[KSXGitHub]

React's references to elements (virtual nodes)

html! {
  <div>
       <div ref="inner-data">Some data</div>
   </div>
}

React deprecated string refs (it's a legacy feature now) and recommends callback refs and object refs instead.

[dkotrada]

Waiting for compiler plugin ...

[huangjj27]

For point 1, as memtion in #128 by DenisKolodin:

If you want to render Link inside any Component you should describe it in type

and I support for component restriction. But it should Render more easy, and hope to just like writing HTML DOM tree.

[andreytkachenko]

Here is I'm finally gathered all my ideas as PoC in one place. Please check it. If you have some ideas how it can be integrated into yew it would be awesome.

[jstarry]

Yew 1.0 Update

We are getting closer to releasing a v1.0 version of Yew and I wanted to address some of the requests here and provide updates :)

1. Collections of Renderable of different type

Currently trait Renderable depends on component, but it is a huge limitation not allowing to create a collection of different kind of components and also not allowing to create nested components (Issue #128) (create container components like Tabs, Stacks, etc.)

Nested Components v1 was completed in #589 and will be matured in v2 here #756 (along with the removal of generics in the virtual dom)

2. React syntax

Reacts componentDidMount analog

Fixed here: #583

Get rid of all confusing commas and semicolons

Fixed here: #500

Allow raw text nodes

Yes, this would be nice, but AFAICT not easy to implement. May come in the future 🤷‍♂ I created an issue here: #757

Components should be able to have a body

Mentioned already, but fixed here: #589

React's references to elements (virtual nodes)

Fixed here: #715

3. Move virtual dom part into seporate crate

Yeah, I think this is a good idea, created an issue here: #758

---

I'm going to close this issue in favour of the 2 new issues I created. Thanks for writing this up @andreytkachenko!