Support setting inner html from string with the `html` macro

Problem

Devs would like to reuse existing templates/snippets for a lot of parts of an application.

They may try using pub const INDEX_HTML: &'static str = include_str!("../assets/templates/index.html"); and then inside html! { <div id="wrapper>{ INDEX_HTML } </div> } but all they will get is the html rendered as plain text inside the wrapper div :(

Proposed Solution

Add a special property like React's dangerouslySetInnerHTML (https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml) to VTag

[weiznich]

I think it would be great to take this idea a bit further: It would be great if it's possible to use only parts of existing html files. See kioo from the clojurescript land for an example of such an library. Don't get confused by the lisp code style. What this library does is basically the following:

• Load a existing html file
• Extract a bit of this html file based on a css selector (in the snippet case, for templates the whole html file is used)
• modify parts of the extracted html file based on further css selectors.

The main benefit of such an strategy is the split between design work (could be done purely based on the html files) and implementing the actual webapp.

Without any further investigation I think is should be possible to implement such an feature as proc-macro based library using the html/css stack from the servo project and then inlining the prebuild template.

[ndarilek]

Came here to ask exactly this, inspired by https://anderspitman.net/2018/04/04/static-react-rust-webapp/. Would be nice to render a Vue app into a single .html file, then include it into the wasm binary directly. Not immediately sure how this would interop with Rust code, though.

I'd rather see integration with something like wasm-bindgen, and support of native HTML/JS/CSS loaded as strings, than of an html! macro with a bunch of edge cases. Suggestion made entirely respectfully--this is a personal project, but it does seem to be biting off quite a bit.

[samuelvanderwaal]

Missing label:

• question

[awaited-hare]

This is very much desired, especially when a webpage contains many static contents. Translating them to JSX manually is a lot of work.

[jstarry]

@l1an0 there is a workaround here: #1281

We could also add a special property like React's dangerouslySetInnerHTML (https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml)

[WorldSEnder]

Revisiting this from #2841, I think the cleanest approach, without touching other parts of yew would be a single fn Html::from_html_unchecked(inner: &str) -> Self. Internally we can already differentiate the rendering modes and decide whether to emit the correct SSR content or to create new nodes.

A detail that most users are probably not aware of, is that setting .innerHtml does not execute <script> tags, but this would be mismatching with SSR - not that's it's such a good idea, but maybe there is some value in executing highlight.js or similar libs. There is an alternative API: Range.createContextualFragment that's quite well supported and does execute scripts when inserted.

In this case, the API could look like:

let inner = Html::from_html_unchecked(INDEX_HTML);
html! { <div id="wrapper>{ inner } </div> }

[dandedotdev]

Recently, I have been trying to use icondata with yew, and I found some issues.

In the following case, the rendered HTML structures are incorrect:

#[function_component]
pub fn App() -> Html {
  let inner_html = r#"<path d="M3 5v14" /><path d="M21 12H7" /><path d="m15 18 6-6-6-6" />"#;

  html! {
    <svg
      xmlns="http://www.w3.org/2000/svg"
      width="24"
      height="24"
      viewBox="0 0 24 24"
      fill="none"
      stroke="currentColor"
      stroke-width="2"
      stroke-linecap="round"
      stroke-linejoin="round"
      class="lucide lucide-arrow-right-icon lucide-arrow-right"
    >
      { Html::from_html_unchecked(inner_html.into()) }
    </svg>
  }
}

The inner part would be like this in the browser:

<path d="M3 5v14">
  <path d="M21 12H7">
    <path d="m15 18 6-6-6-6"></path>
  </path>
</path>

Hence, the svg is broken.

I also tried to use div, and I found the result was similar.

#2841

[WorldSEnder]

@dandedotdev this was adressed in #3640 I think. Code in master should correctly infer the namespace when parsing the <path> elements.