Skip to content
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

Expose @vue/server-renderer renderToString as esm module #3111

Closed
leemason opened this issue Jan 27, 2021 · 2 comments
Closed

Expose @vue/server-renderer renderToString as esm module #3111

leemason opened this issue Jan 27, 2021 · 2 comments

Comments

@leemason
Copy link

leemason commented Jan 27, 2021

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:

  1. always export ssrUtils from runtime-core
  2. 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:

  1. there are problems i haven't seen in allowing this type of usage
  2. exposing via the browser may in future prevent needed updates that can only be performed in a nodejs environment (although i cant see why)
  3. 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.

@frandiox
Copy link

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.

@klarkc
Copy link

klarkc commented Jun 1, 2021

+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).

https://github.com/vuejs/vue-next/blob/44996d1a0a2de1bc6b3abfac6b2b8b3c969d4e01/packages/runtime-core/src/index.ts#L280

@github-actions github-actions bot locked and limited conversation to collaborators Oct 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants