Replies: 3 comments 3 replies
-
|
I thought about it more. I kind of like the idea of injecting the module from WASM. If it was done that way, the module would work automatically with both CSR and SSR versions without having to deploy with Actix or Axum. It also would be compatible with most WASM deployments, as it just needs to be able to find the document. I did some searches and found there are some tricks to inline ESM modules, so I might try to do something similar. I also looked through wasm_bindgen again, and noticed that using [wasm_bindgen(inline_js="")] creates snippets which Leptos seems to include correctly, but I don't think there's currently support for static strings with it. I noticed an author for Dixous had opened an issue on wasm_bindgen for inline &str support for it, but I don't think it has changed. I don't know, I might try some of these later, but if there's a better way to do this, I would prefer to do that instead. An easy solution would be to just use like unpkg and link to it in the bindings, but I think that's more unreliable than the above. I've also had many experiences where unpkg seemed to be broken, so I kind of want to avoid doing it that way. |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to close this discussion because I created a discussion on the wasm_bindgen repository instead. I think this question is more relevant to that repository after my last comment. |
Beta Was this translation helpful? Give feedback.
-
|
You can use Leptos with Webpack to bundle npm packages easily. More info: #2333. I'm not sure if this would work perfectly for you if you want the server to be written in Rust and not JS. |
Beta Was this translation helpful? Give feedback.
-
|
I was kind of feeling opinionated when I originally made my post. The issue is that there's not a standard for binding distribution. I think ESM CDN distribution (I linked to an example I wrote for someone else) is probably going to be the easiest for most people, but it makes crates highly dependent on the CDN. Without that, it feels like it will end up requiring each person using crates with bindings to follow custom build steps for each dependency. That seems like it could become very problematic fast. There's also like developers that seem to want to stay away from that ecosystem. I do think webpack integration is the most optimal solution for performance, but that makes rust developers also have to manage JS and TS dependencies, which I don't really know if that's the right solution. The solution I like the most, which I'll probably use for my crates, is to create two versions.
In this issue on wasm-bindgen someone commented that it's possible to just create JS bindings in the like global module namespace as an object, (not tied to an import) then take an import and add the functions to a JS object and then just convert it into the JS object with bindings to use the bindings. Imports can be added at runtime by using blobs, etc. Anyway, that's how I think I'm going to solve it, but I think it also would be good if Leptos directly supported the more complex build system with NPM, webpack, etc. |
Beta Was this translation helpful? Give feedback.
-
I don't see the problem with "having to manage JS dependencies" if all it means is adding one line to |
Beta Was this translation helpful? Give feedback.
-
|
I just want it to be easy for crates that I create so there’s never a developer who isn’t immediately able to use my crate. I understand there are developers who want to have the most optimal build, and will follow instructions to reduce duplication of dependencies in their node modules, [1] etc. I don’t think they need much help. I personally think that even if it’s not the most optimal build, it’s much better that they were able to use it by just doing “cargo add” than having to follow specific build instructions that aren’t consistent. As an example, rayon, which doesn’t even use bindings already has steps [2] that require developers to include it in their page from JS. These steps are usually not difficult, but they’re just not as consistent as using something like “cargo add” and being done. If it's really as simple as stated, then I don't see why npm, webpack, typescripts compiler, etc. isn't just directly integrated into cargo. Anyway, it's partially that I'm just slightly unreasonable too. I understand that even if I do create two versions, the easier version isn't always going to work etiher. (modules won't be recognized correctly by other modules which can cause issues, etc) Though, I don't think really think it's going to be too much of an issue [1] https://docs.npmjs.com/cli/v7/commands/npm-dedupe |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I want to create a crate with bindings for a bundled NPM module to be used in Leptos.
The goal of doing this is so that rust developers using Leptos do not have to think about the complex build system related to JS, TS, webpack, etc. I understand that there are negative performance and fuctionality impacts from pre-bundling, but, I would prefer to encourage rust developers to create rust library versions of the binded version instead of encouraging every rust developer that uses the crate to understand another language's build system.
At the moment, with my own project that uses Leptos, I've handled this issue by adding the bundle to a location that Actix in Leptos makes accessible online. This works for my project, but, I would prefer for a developer that uses my crate to not have to think about where bundles are being stored for use with Leptos.
Is there a suggested way to accomplish this goal? I don't want a developer that is using multiple crates with bindings to have to follow different instructions for each crate. I would prefer for them to be able to add the crate to their project, and have it work automatically.
Beta Was this translation helpful? Give feedback.
All reactions