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

Support for dynamic HTML element tags inside html macro #1049

Closed
cit117 opened this issue Mar 23, 2020 · 8 comments · Fixed by #1266
Closed

Support for dynamic HTML element tags inside html macro #1049

cit117 opened this issue Mar 23, 2020 · 8 comments · Fixed by #1266
Labels

Comments

@cit117
Copy link

cit117 commented Mar 23, 2020

Please support for dynamic changes to the HTML elements inside html macro,so that the following compiles:

fn view(&self) -> Html {
        html! {
                <{self.props.tag}>
                <h2>{self.props.title}</h2>
                </{self.props.tag}>
            }
    }
@cit117 cit117 added the feature-request A feature request label Mar 23, 2020
@jstarry jstarry changed the title Support for dynamic changes to the HTML elements inside html macro Support for dynamic HTML element tags inside html macro Mar 23, 2020
@jstarry
Copy link
Member

jstarry commented Mar 23, 2020

I think this would be a fun issue to take on for someone interested in how the macro works! I think we would probably need to require that the expression inside the curly braces is exactly the same for the open and close tags to have proper compile time error checks.

@captain-yossarian
Copy link
Contributor

@jstarry I'd like to work on it

@jstarry
Copy link
Member

jstarry commented Apr 4, 2020

Alright, have fun!

@captain-yossarian
Copy link
Contributor

captain-yossarian commented Apr 4, 2020

@jstarry Could you please give me start point?
Like I understand, html! macro defined here, am I right?

Should I treat computable tag name as a tag, or I should add new type HtmlTree::Computable?

Should parsing logic go here?

How you debug your changes?
I tried to use wasm_log, but every time I'm receiving use of undeclared type or module wasm_logger`` when I want to initialize it.

Also, I've tried to use console service, but

use cfg_if::cfg_if;
use cfg_match::cfg_match;

above code don't work

Thanks!

@jstarry
Copy link
Member

jstarry commented Apr 4, 2020

Should I treat computable tag name as a tag, or I should add new type HtmlTree::Computable?

Treat it as a tag 👍

Should parsing logic go here?

Yes 😄

How you debug your changes?

For this stuff, I try to write tests first. If you want to do debug printing, you will have to add a dependency to wasm logger on the yew-macro crate

@jstarry
Copy link
Member

jstarry commented May 24, 2020

We can't rely on expressions resolving to the same string for start and end tags. I think we will need to special case end tags to something like </{}>

@siku2
Copy link
Member

siku2 commented May 24, 2020

@jstarry I was just toying around with this a bit over at siku2/yew@dynamic-tag and I noticed this exact problem:

We can't rely on expressions resolving to the same string for start and end tags.

However, my approach introduces a new syntax using the @ token.
It looks like this:

let wrapper_tag  = "div";
let mut extra_iter = vec!["a", "b"].into_iter();
html! {
    <@{wrapper_tag}>
        <span>"Hello World"</span>
    </@>

    <@{extra_iter.next().unwrap()} class="extra-a"/>
    <@{extra_iter.next().unwrap()} class="extra-b"/>
}

The benefit of doing it this way is that it's immediately obvious that it's not a normal HTML tag and personally I think the closing tag </@> is much nicer than </{}>.
What do you think?

@jstarry
Copy link
Member

jstarry commented May 26, 2020

@siku2 sounds reasonable to me. I'm not too worried about the syntax here since I don't expect this to be super common. Using @ is very unlikely to interfere with anything else 👍

@siku2 siku2 mentioned this issue May 26, 2020
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants