You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allowing the usage of the ssr functionality outside of a nodejs environment.
Im having some pretty wild ideas about how to use some of the new features in vue 3. My latest is rendering the component to a string which is already possible using the server-renderer package.
The problem i have is my use case isn't going to be in a nodejs environment. Its directly in the browser.
And this got me thinking about if there are any technical reasons the server renderer cannot work in a none nodejs environment.
A little investigation has lead me to be belive this is possible with some minor none-breaking changes to the current exports:
always export ssrUtils from runtime-core
build the sever renderer with esm as a target
The above is all i believe is required to allow browser usage of the server renderer for rendering to strings.
Additional steps would need to be taken for rendering to stream, either choose not to expose it in this way, or by providing a stream implementation (eg: https://www.npmjs.com/package/stream-browserify).
I totally understand this is a none standard use case, and the name "server renderer" might mean this gets shot down pretty quickly. But it seems at least currently this is a very easy thing to expose.
There may be some reasons not to allow this, which may already be why this isn't exposed:
there are problems i haven't seen in allowing this type of usage
exposing via the browser may in future prevent needed updates that can only be performed in a nodejs environment (although i cant see why)
it confuses the api (or the name at least)
Maybe renderToString shouldn't be in the "server-renderer" package but a "string-renderer" package, and vice versa for stream rendering? I can also imagine a scenario rendering apps to strings could be useful in web/service workers, which is currently not possible as they don't have access to the dom, or the renderToString method.
What does the proposed API look like?
The api doesnt change, its the addition of renderToString exposed in none nodejs environments.
The text was updated successfully, but these errors were encountered:
I'm trying to use renderToString in Cloudflare Workers and right now it only works because Webpack adds some magic to mock the stream dependency. It would be great to have ESM build for this so we can just import renderToString without bringing the whole package.
+1 In my use case, we're using native esm in the server and in the client. Even running in the server, because ssrUtils use CJS to detect the node target, it assumes that is not a SSR (which is not true).
What problem does this feature solve?
Allowing the usage of the ssr functionality outside of a nodejs environment.
Im having some pretty wild ideas about how to use some of the new features in vue 3. My latest is rendering the component to a string which is already possible using the server-renderer package.
The problem i have is my use case isn't going to be in a nodejs environment. Its directly in the browser.
And this got me thinking about if there are any technical reasons the server renderer cannot work in a none nodejs environment.
A little investigation has lead me to be belive this is possible with some minor none-breaking changes to the current exports:
ssrUtils
from runtime-coreThe above is all i believe is required to allow browser usage of the server renderer for rendering to strings.
Additional steps would need to be taken for rendering to stream, either choose not to expose it in this way, or by providing a stream implementation (eg: https://www.npmjs.com/package/stream-browserify).
I totally understand this is a none standard use case, and the name "server renderer" might mean this gets shot down pretty quickly. But it seems at least currently this is a very easy thing to expose.
There may be some reasons not to allow this, which may already be why this isn't exposed:
Maybe
renderToString
shouldn't be in the "server-renderer" package but a "string-renderer" package, and vice versa for stream rendering? I can also imagine a scenario rendering apps to strings could be useful in web/service workers, which is currently not possible as they don't have access to the dom, or the renderToString method.What does the proposed API look like?
The api doesnt change, its the addition of
renderToString
exposed in none nodejs environments.The text was updated successfully, but these errors were encountered: