What causes "Expected to find a #modal_host element" in yewstack/yew?

Expected to find a #modal_host element

Error message

Expected to find a #modal_host element

What it means

This panic is the `.expect("Expected to find a #modal_host element")` after `get_element_by_id("modal_host")` in Yew 0.23's portals guide. `get_element_by_id` yields `Option<Element>`, None when no element with that exact id exists in the document. The guide's contract is that your static `index.html` declares the portal destination with `id="modal_host"` before `<Modal>` mounts; the panic signals that contract was not met.

Source

Thrown at website/versioned_docs/version-0.23/advanced-topics/portals.mdx:38

Note that `yew::create_portal` is a low-level building block. Libraries should use it to implement
higher-level APIs which can then be consumed by applications. For example, here is a
simple modal dialogue that renders its `children` into an element outside `yew`'s control,
identified by the `id="modal_host"`.

```rust
use yew::prelude::*;

#[derive(Properties, PartialEq)]
pub struct ModalProps {
    #[prop_or_default]
    pub children: Html,
}

#[component]
fn Modal(props: &ModalProps) -> Html {
    let modal_host = gloo::utils::document()
        .get_element_by_id("modal_host")
        .expect("Expected to find a #modal_host element");

    create_portal(
        props.children.clone(),
        modal_host.into(),
    )
}
```

## Event handling

Events emitted on elements inside portals follow the virtual DOM when bubbling up. That is,
if a portal is rendered as the child of an element, then an event listener on that element
will catch events dispatched from inside the portal, even if the portal renders its contents
in an unrelated location in the actual DOM.

This allows developers to be oblivious of whether a component they consume, is implemented with
or without portals. Events fired on its children will bubble up regardless.

View on GitHub (pinned to 0e4a05472f)

Solutions

Add `<div id="modal_host"></div>` to `index.html`
Check the exact id spelling/casing on both sides
Degrade gracefully with `if let Some(host)` and skip or log instead of panicking when the host is missing
Ensure the portal component mounts after DOM parsing (module/defer scripts)

Example fix

// before
let modal_host = gloo::utils::document()
    .get_element_by_id("modal_host")
    .expect("Expected to find a #modal_host element");

// after
match gloo::utils::document().get_element_by_id("modal_host") {
    Some(host) => create_portal(props.children.clone(), host.into()),
    None => html! { <p>{"missing #modal_host"}</p> },
}

Defensive patterns

Strategy: validation

Validate before calling

if gloo::utils::document().get_element_by_id("modal_host").is_none() {
    gloo::console::warn("#modal_host missing in index.html");
    return html! {};
}

Prevention

Declare portal host divs in the static index.html shell
Centralize host ids in constants shared between HTML and Rust
Add a startup check listing every portal host id the app expects
Render a placeholder instead of panicking when a host is absent

When it happens

Trigger: Rendering `<Modal>` when the page shell has no `<div id="modal_host"></div>`; id typo or casing mismatch; the host div removed during a template redesign; tests rendering the component into a document without the host.

Common situations: Copy-pasting the 0.23 portals example without editing `index.html`; switching Trunk templates; SSR or hydration setups where the host is added after first render.

Related errors

AI-assisted analysis of yewstack/yew@0e4a05472f (2026-08-22). Data as JSON: /api/errors/71f3229dfde55e81. Report an issue: GitHub.