Skip to content

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

@leemason

Description

@leemason

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions