relocation of nestedly imported js in wasm_bindgen about leptos HOT 3 CLOSED

Which build tool are you using? Judging by the output I'm guessing Trunk, right?

While you could open an issue in the Trunk repo, I really think it's just a matter of using a relative import in a JS file and not using a JS bundler. But then again, I do everything I can to avoid JS and its bundling ecosystem, so I'm not really sure.

I do not think this has anything to do with Leptos.

from leptos.

Which build tool are you using? Judging by the output I'm guessing Trunk, right?

While you could open an issue in the Trunk repo, I really think it's just a matter of using a relative import in a JS file and not using a JS bundler. But then again, I do everything I can to avoid JS and its bundling ecosystem, so I'm not really sure.

I do not think this has anything to do with Leptos.

Ty for the timely reply. I ended up declaring a dummy extern js and log it in the use_effect of component, which tricked trunk to include the relatively imported file in the final bundle.

I definitely agree with the idea of avoiding js...but I don't know the proper UI libraries that help with highlighting/animation and other UI manipulations, so I fall back to use highlight.js in the project but there're SO many gotchas b/c of it messing up the DOM, and I ended up having a complex & inelegant code that

1. having a singleton list with its key cloned each time to force the dom re-render
2. use a provider and derived signals to handle the update logic
3. declare all extern js and invoke them in use_effect

Do you know any Rust libraries that provide a more neat and elegent solution?

from leptos.

I don't have any advice on the particular topic of highlighting/a replacement for highlight.js. What you're describing (gotchas because of it messing with the DOM) makes it sound like it would be a hard library to integrate with any framework. In general in those cases (the JS library wants to modify the DOM in ways it can't tell the framework about) it's fine to use them, you just can't integrate them with any kind of reactive change -- i.e., you can say "Ok, highlight.js, you're going to take over this <div>," and know that you can never reactively update anything in that div because the framework no longer owns it." ("Owns" might be a good word there -- this can't be enforced by the compiler of course but it's similar to the Rust ownership concept, you are giving ownership over those DOM nodes to the other library.)

from leptos.