dioxus icon indicating copy to clipboard operation
dioxus copied to clipboard

dioxus_web::launch_cfg cannot be called multiple times on different root elements.

Open JJJHolscher opened this issue 1 year ago • 3 comments

Problem

When trying to have multiple dioxus widgets on different pre-existing elements, the browser console will tell about the fact that null has no property X, where X can be listeners or nodeType when calling dioxus_web::launch_cfg for the second time using either a Config::rootname or Config::rootelement on an element that is not a child of first root element.

Steps To Reproduce

  • Clone my repo and cd into it.
  • Checkout to 3f5abc55ba1981a8fcb0e2d13915834f238ba0bb
  • Make sure you have wasm-pack.
  • cmd/build
  • python -m http.server 8080
  • $BROWSER http://localhost:8080

My repo works with custom elements, but my exposed change function can also be used to launch dioxus on an element given its id, and you will again notice that this function errors when dioxus was already launched, either because there was already a rendered custom element or because the function was called before on a different id.

Expected behavior

When pointing the browser to index.html, you only see a single group of 2 buttons + 1 header. I expect there to be two groups, since there are two custom elements in index.html. Instead, there is the aforementioned error in the console.

Screenshots

image

Environment:

  • Dioxus version: commit dc5e4e3738ac80cb3e333a10340674b575c95abd (<2 weeks old)
  • Rust version: 1.76.0-nightly
  • OS info: ArchLinux
  • App platform: web

Willingness to solve this myself I'm interested in fixing this myself but don't know where to start. If there is a way to solve this without using dioxus_web, that's also fine by me. I just want multiple dioxus widgets without all those widgets necessarily having to share the same root element, since I'm using dioxus inside a pre-existing html that sometimes adds new elements itself (I want dioxus widgets inside a jupyter notebook's cell output). If my goal is doable with a single dioxus root, then that's also fine (I did not try this yet), but my gut tells me dioxus won't play nice with external sources adding (complex) elements.

Bug or Feature I've seen no mention or examples of multiple dioxus_*::launch calls, maybe I am merely mistaken in thinking this is possible to do, in which case this issue is moreso a combination of a feature request; a call for help; and a mention that the documentation has not been clear to me about the role of launch calls. If Dioxus is not the right tool for my job, then this might deserve mention, for example here https://github.com/DioxusLabs/dioxus/issues/1359.

Links

JJJHolscher avatar Feb 06 '24 07:02 JJJHolscher

Here is the complete error message with debug flags enabled. image Those websocket errors only occur with the debug flags.

JJJHolscher avatar Feb 06 '24 14:02 JJJHolscher

Iframes provide a workaround. You can have 1 dioxus_web::launch in another html file, which you look at through an iframe. This way you can have multiple interactive dioxus widgets accessible from a single page. Unfortunately I need to now make a new html file per widget, but at least I'm no longer stuck.

index.html

<!doctype html>
<html lang="en">
  <body>
    <iframe src="other.html"></iframe>
    <iframe src="other.html"></iframe>
  </body>
</html>

other.html

<!doctype html>
<html lang="en">
  <head>
    <title>Im in an iframe</title>
    <script type="module">
      import init, { run, change } from './pkg/jupyter_and_dioxus.js';
      window.change = change;
      async function main() {
        await init();
        run();
      }
      main();
    </script>
  </head>
  <body>
    <ce-dioxus>What happens to you?</ce-dioxus>
  </body>
</html>

result in the browser image

JJJHolscher avatar Feb 06 '24 14:02 JJJHolscher

This should definitely be possible and might be a side effect of how we do event delegation actually. I'll take a look soon - should be simple to fix.

jkelleyrtp avatar Feb 06 '24 17:02 jkelleyrtp

Revisiting this - it's likely because we use the same interpreter for all virtualdom instances and there's a data race happening.

Going to be fixed in #1974

jkelleyrtp avatar Feb 24 '24 20:02 jkelleyrtp

I got around to testing this and the problem is resolved. Thank you

JJJHolscher avatar Mar 17 '24 10:03 JJJHolscher

I got around to testing this and the problem is resolved. Thank you

0.5.0-alpha.2 is out now with this fixed if you want a released version to work from :)

jkelleyrtp avatar Mar 18 '24 18:03 jkelleyrtp