Need a proper way to handle mounting and remounting Bevy in a SPA (React/Angular/Vue)

[Sieabah]

I originally made this on Discord with little to no engagement so I figured I could also just post it here because this seems like a pretty critical issue for Bevy on the web/wasm platform. This original post will include all the content I put on Discord.

Does anyone have a known good way to handle mounting bevy in React/Angular? I've managed to get it to mount to the canvas but I'm running into issues when trying to remount or restart the engine when the component is remounted. When the component is unmounted I modify an atomic bool to "quit" bevy using

exit.send(AppExit);

When I try to remount the engine by calling app.run() it throws Failed to build event loop: RecreationAttempt

--

I know there are ways to unsocket the existing component through portaling, but that still leaves the engine "running" in the background meaning despite not being able to see what's going on the engine is still taking up a huge amount of CPU.

I've tried condvar but that isn't supported in the wasm environment either.

--

Also seems like if the canvas ever leaves the page the engine keeps ticking but can't recover

System 'bevy_ecs::event::event_update_system<bevy_asset::event::AssetLoadFailedEvent<bevy_audio::audio_source::AudioSource>>' has not run for 3258167296 ticks. Changes older than 3258167295 ticks will not be detected.

I'm able to get the app to mount once and only ever once. If the canvas is unmounted or stored separately from the dom Bevy siezes and never seems to recover even if the canvas returns to the page. The CPU explodes to 200-300% when the canvas leaves the page. If the page is running for long enough on the original mount it will eventually die leaving logs saying "nothing sent to wgpu"

Just tested it out same issue for me. I can't setup my app again after sending AppExit. I wonder if there's a way to pause the winit update loop? Either way the winit loop should be properly cleaned up when AppExit is sent.
Maybe https://docs.rs/bevy/latest/bevy/winit/enum.UpdateMode.html#variant.Reactive can be used in the meantime?

~ connor guy

I'm unsure whether the above is required, but I do think it's Bevy is not correctly "cleaned up" when it exits in a wasm environment. I do wonder if it is possible to get around this by not actually "exiting" and just managing the canvas as a separate window. Using DontExit and when the "primary window" is gone I just create a new window and mount it to the new canvas.

It does seem that it may have been intentional to not support changing the underlying canvas.
.

I have nothing complicated in my Bevy application, it's the gizmo example with some additional stuff to lazily initialize bevy, essentially creates and starts the app from a JS invocation (wasm-bindgen) instead of it being part of main{}.

---

With all of that said, I do think this should be a supported flow for Bevy as I'm unsure if any website that used Bevy for their game wouldn't be able to load the same payload twice. Just going to the game, navigating back, then reopening the game in any regular SPA would error out. I think most sites, including ones like itch.io open the game in a separate tab or load it as an iframe so that the app context isn't muddied. It also somewhat limits the ability integration with the parent application.

[Sieabah]

I found a way around this for now, it's not great but it works. Use an iframe with an "embeddable" view of your bevy app and use that as the "component".

[R2rho]

@Sieabah did you ever find a better solution for this? Also can you share your code on your implementation? I'm trying to do something similar. Seems strange that with so many SPA frameworks out there, you'd think there'd be a straightforward way to remount the window to a newly created canvas when navigating between different routes or tabs on a page, depending on where you're rendering your wasm bundle.

[Sieabah]

Unfortunately, no. I had to step away from this project for a bit.

Some thoughts around it are to create a long-lived component that uses a portal to be displayed. I think I ran into issues with visibility causing an optimization to pause/break the canvas. I imagine that would be the best route outside of a PR for bevy to support a detached-canvas renderer.