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

[labs/context] SSR compatibility #3301

Closed
1 task done
justinfagnani opened this issue Sep 22, 2022 · 6 comments · Fixed by #4755
Closed
1 task done

[labs/context] SSR compatibility #3301

justinfagnani opened this issue Sep 22, 2022 · 6 comments · Fixed by #4755
Assignees

Comments

@justinfagnani
Copy link
Collaborator

Should this be an RFC?

  • This is not a substantial change

Which package is this a feature request for?

Context (@lit-labs/context)

Description

Before graduating @lit-labs/context and @lit-labs/ssr we should implement context support in SSR. This may be done via general event support in SSR as in #2309, or if that's not feasible, in some other way.

Alternatives and Workarounds

None

@hrmcdonald
Copy link

It sounds like #3365 will help address this, but until it does, could @lit-labs/context be updated to not break SSR by not attempting to attach event listeners during SSR via the use of isServer checks?

If the priority of this is high enough that event support will be coming to SSR sooner than later this probably isn't necessary though.

@justinfagnani justinfagnani self-assigned this Dec 7, 2022
@dunqan
Copy link

dunqan commented Feb 1, 2023

We really support @lit-labs/context idea, and it would be really nice to have it working seamlessly with SSR, but our main worries are:

  1. It uses an Event based protocol, super nice solution on CSR, doesn't look so nice on SSR, but it looks like Lit is trying to push SSR support for Events because of this.

If lit SSR is a liniear process, idea of dispatching event to the parent (when the parent is partially rendered already) looks like not complete one (but I agree, will work for limited use cases, like context implementation).

  1. What about partial hydration, when child component was hydrated before parent was able to setup event listeners?

Did you consider any mechanism of serializing context, so child ements are able to pick it up from the DOM on hydration, without having to hydrate parent first?

@bennypowers
Copy link
Collaborator

bennypowers commented May 19, 2024

shouldn't the provide controller attach the listener in hostConnected anyways, rather than in the constructor? Our context implementation does not crash SSR, so long as DOM *Observers are shimmed.

https://github.com/RedHat-UX/red-hat-design-system/blob/cbd5fec0099cd6c8bfedc8b3c1bfd4a94969d4a3/lib/context/color/provider.ts#L104-L110

Why do the listeners need to be attached in the constructor?

@justinfagnani
Copy link
Collaborator Author

@sorvell I'm not sure this should be closed yet. Event support is opt-in and not documented.

@kyubisation
Copy link
Contributor

Sorry, that's on me, as I referenced this issue in my PR. Feel free to re-open this.
I can try to add appropriate documentation to lit.dev in January.

@kyubisation
Copy link
Contributor

lit/lit.dev#1390

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

Successfully merging a pull request may close this issue.

5 participants