docs: add a note about transport between the server and the runner #17660
Conversation
|
|
docs/guide/api-vite-environment.md
Outdated
| return source === 'virtual:index-html' ? '\0' + source : undefined | ||
| }, | ||
| async load(id, _options) { | ||
| if (id === '\0' + 'virtual:index-html') { |
There was a problem hiding this comment.
Should we expose this as something like runner.html(url, htmlPath)? Feels weird that every framework now has to implement this
There was a problem hiding this comment.
To support runner.html(), we would have to ask for fetchHtml method alongside fetchModule (right now transport only requires fetchModule) - or I guess we can also have an option like html: true 🤔
There was a problem hiding this comment.
I use index.html for my quick setup (and also create-vite-extra template too e.g. https://github.com/bluwy/create-vite-extra/blob/master/template-ssr-react/server.js), but in practice, I'm not sure if actual framework would benefit from this since they usually have more opinionated way to generate the html shell.
At least for the frameworks I'm aware of, they don't have index.html convention. Instead, they have only "client entry" script and they can use it as rollupOpitons.input. They also have an access to client build manifest, so they can find "production client entry" asset path from manifest and renders <script> (also <link> for css, preload, etc...) on their own into their html shell.
So, I think having runner.html() would help only "entry level" ssr framework exploration and I'm not sure if it's worth it to have in core. For that case, showing this virtual:index-html idea here is probably helpful enough.
|
@hi-ogawa added last note, pls check |
sheremet-va
force-pushed
the
docs/env-transport-virtual
branch
from
60a7c9f
to
f1bf2f6
Compare
Description
Added our current thoughts about the transport API. @hi-ogawa do you have any thoughts? I am open to discussion.