Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement "Fragment" syntax for html! macro #36

Closed
wldcordeiro opened this issue Dec 28, 2017 · 5 comments
Closed

Implement "Fragment" syntax for html! macro #36

wldcordeiro opened this issue Dec 28, 2017 · 5 comments
Milestone

Comments

@wldcordeiro
Copy link
Contributor

It'd be great if you could do something like the Fragment syntax from React in the macro to avoid wrapping things in unnecessary divs.

fn view(model: &Model) -> Html<Msg> {
    html! {
        <>
            <section class="todoapp",>
               ...
            </section>
            <footer class="info",>
                ...
            </footer>
        </>
    }
}
@therustmonk therustmonk added this to the 0.2.0 milestone Jan 2, 2018
@therustmonk
Copy link
Member

Useful thing! 👍 I need to think how to implement it.

@remexre
Copy link

remexre commented Jan 2, 2018

Would it also make sense (at least in the short term) to allow the html! macro to expand to either Html<Msg> or Vec<Html<Msg>>, depending on whether one or multiple DOM trees are present?

@wldcordeiro
Copy link
Contributor Author

@remexre I think fragments would be the equivalent of Vec<Html<Msg>> if I'm interpreting what React does into Rust properly. It's essentially a way to wrap up an array/vector of components/elements.

@remexre
Copy link

remexre commented Jan 2, 2018

Sure, but there'd still be the matter of whether html! expands by:

  • Always Html<Msg>, change VNode<Msg> to have a "multiple children" variant
  • Sometimes Html<Msg>, sometimes Vec<Html<Msg>>
  • Always Vec<Html<Msg>>
  • Redefine Html<Msg> = Vec<VNode<Msg>>
  • Maybe something like Html<Msg> = ArrayVec<[VNode<Msg>; 1]>, which would mitigate the performance loss in the single-element case of needing a pointer dereference.

@therustmonk
Copy link
Member

Solved with #122

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants