Exploring a vite plugin #73
Replies: 2 comments 1 reply
-
Currently the plugin takes the WebViewOptions as a parameter and uses the vite server's url Next I'm thinking through the best way to hook into the webview's event emitter as well as make its functions accessible Taking a look at electron but also trying to take a first principles approach |
Beta Was this translation helpful? Give feedback.
-
It seems to me like there are two sides of this. There's the client code, which is the most straight forward. That's just being injected directly into the webview via the vite plugin. The server side is the wrapper around the webview. Another way of handling this is to have another entry point that's really just focused on being the "server side" component. This problem makes me think a bit of WXT's entrypoints. WXT is a framework for building browser extensions. There's a lot of different contexts for those extensions. We could do something slightly similar where we expose an entry point that's dedicated to managing the webview. That file could export something like this export default defineWebView({
// ... config
main(webview) {
// Do stuff with the webview here
}
}) I don't know if this library being written in deno complicates that workflow though. |
Beta Was this translation helpful? Give feedback.
-
Be able to use a vite plugin and reap the benefits of HMR etc
Beta Was this translation helpful? Give feedback.
All reactions