-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
Add frontend render plugin system support #36099
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Don't understand why wasm is introduced and becomes a must. It's highly likely a wrong design: when you have a hammer, then everything in your eyes become nails. |
|
I'm still of the opinion that plugins should be npm packages with a package.json that declares their metadata and dependencies. I don't think it's good to create a new The big benefit of being a npm package is that these plugins can be puplished to the npm registry so be installed from there or a local folder. Take for example VSCode extensions, those are also npm packages at their core, with additional package.json properties specific to extensions. |
WASM support is nice, but it should not be required. The entry point to a plugin should be JS function, and whether the plugin than loads a WASM module or not is the plugin's decision. |
WASM is definitely a new abuse here, unless it could prove that it brings real benefits. |
It's just an example. There is no special code to support wasm. It's a nature support from web browser. The benefit of wasm could allow render plugin reuse the legacy code written by other lanuages. i.e. https://github.com/xuri/excelize-wasm could render excel file in the web browser which used wasm. |
|
Perhaps Obsidian's plugin solution will be helpful to us: https://docs.obsidian.md/Plugins/Getting+started/Build+a+plugin |
Resolve #34917