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

Svelte 5: Rename rendered.html to rendered.body #11281

Closed
Rich-Harris opened this issue Apr 21, 2024 · 7 comments · Fixed by #11927
Closed

Svelte 5: Rename rendered.html to rendered.body #11281

Rich-Harris opened this issue Apr 21, 2024 · 7 comments · Fixed by #11927
Assignees
Milestone

Comments

@Rich-Harris
Copy link
Member

Describe the problem

very minor annoyance, but it always irks me a bit that the render(...) return value has head and html properties rather than head and body

Describe the proposed solution

Return a { head, html, body } object where html and body are identical, but html is marked as deprecated in the types. Eventually, have an explicit warning when result.html is accessed, and remove it in Svelte 6 (by which time tooling like SvelteKit will have updated).

Importance

nice to have

@Rich-Harris Rich-Harris added this to the 5.0 milestone Apr 21, 2024
@Conduitry
Copy link
Member

There's been a very long-standing issue about people wanting to be able to attach (primarily) classes to the <body>, which we've put off because of a lack of a way to return those in SSR. Do we want to think about an API for that while naming this? If we do add that feature, would we be able to get away with not calling it a breaking change? It sounds tricky to wriggle out of that one, because there would be a new returned string that people directly consuming the SSR version of a component would have to do something with.

@Rich-Harris
Copy link
Member Author

Good question. I think it'd be fine to do it in a minor — even though you can technically do <svelte:body class="blah" />, no-one would since it doesn't do anything today.

Perhaps an API like this, with attributes added in a later version?

declare function render(component, opts): {
  head: string;
  body: string;
  attributes: {
    root: Record<string, string>;
    body: Record<string, string>:
  }
}

@Conduitry
Copy link
Member

For the breaking change, what I meant was that, if someone were calling the render function manually, there would now be a new value returned that they would be expected to deal with, otherwise the components they're rendering wouldn't have everything the authors of those components would expect.

If we wanted to, we could address the breaking change you're discussing by making things like <svelte:body class='blah'> a syntax error in 5.0 and relaxing it when we implement the feature - but that doesn't resolve the issue of adding new values to the response from render. Those would also, probably, need to be returned right away in 5.0 - and documented as a breaking change - but they would initially all be empty strings.

@Rich-Harris
Copy link
Member Author

I suppose the alternative solution is to just go ahead and implement attributes? In the case of <svelte:body>, #11046 will raise its head again

@PatrickG
Copy link
Member

Shouldn't it be bodyAttributes then?
Or body: { attributes: string; html: string }

@trueadm
Copy link
Contributor

trueadm commented Jun 4, 2024

This would be quite invasive to do in the RC, I wonder if we should just push it back to Svelte 6?

@Rich-Harris
Copy link
Member Author

What about just marking the property as @deprecated in TypeScript but not issuing a warning? That way users of things like SvelteKit would be unaffected — the only people who would notice are the people using the render API directly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants