-
Notifications
You must be signed in to change notification settings - Fork 939
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
Comments
It sounds like #3365 will help address this, but until it does, could 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. |
We really support
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).
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? |
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 Why do the listeners need to be attached in the constructor? |
@sorvell I'm not sure this should be closed yet. Event support is opt-in and not documented. |
Sorry, that's on me, as I referenced this issue in my PR. Feel free to re-open this. |
Should this be an RFC?
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
The text was updated successfully, but these errors were encountered: