-
Notifications
You must be signed in to change notification settings - Fork 601
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
feat: add defer-hydration
to ssr renderer
#6492
feat: add defer-hydration
to ssr renderer
#6492
Conversation
…tps://github.com/microsoft/fast into users/nirice/add-defer-hydration-to-ssr-renderer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main thoughts are:
- I think NOT deferring hydration should probably be the default.
- Shouldn't there be a way to specify which elements should defer rather than it being an all or nothing?
|
||
This attribute is added automatically during custom element rendering to all FAST custom elements. If your app does not require orchestrating element hydration, emission of this attribute can be prevented by configuring the renderer: | ||
```ts | ||
const { templateRenderer } = fastSSR({deferHydration: false}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we should flip the default on this. Seems like most folks working with the library will want to hydrate automatically, yes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went back and forth on it. I think most applications of a reasonable size will want to defer hydration because they'll have services and contexts that will need to get set up, so hydration order will matter. We can still make it opt-in though, if that is a more predictable interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think switching the default to be false
is probably more what's expected, especially if someone is getting started.
I think there could be, yes. Either by element CTOR or by element instance. Another approach applications can take is to handle that logic in client-code. For example, hydration modes of "immediate" (remove attribute immediately), "enter" (remove attribute when the element enters the viewport), "interactive" (mouseover, click, focus). These are all features we can explore as follow-ups. I'll make the change to make defer-hydration opt-in. That will make it easier to expand that configuration option with additional types to support CTOR or callback options for fine-grain control. |
* yield defer-hydration attribute when configured * Make defer-hydration the default behavior, fixing tests * adding disable deferHydration test * update readme * update config comments * fixing documentation * Change files * update API report * make deferHydration false by default Co-authored-by: nicholasrice <nicholasrice@users.noreply.github.com>
Pull Request
📖 Description
This PR adds
defer-hydration
attribute emission to@microsoft/fast-ssr
. When configured,@microsoft/fast-element
will wait until the attribute is removed to hydrate its view and connect its behaviors.🎫 Issues
👩💻 Reviewer Notes
📑 Test Plan
✅ Checklist
General
$ yarn change
Component-specific
⏭ Next Steps