Zengtudor/Nuxt
1
0
Fork 0
mirror of https://github.com/nuxt/nuxt.git synced 2024-11-11 08:33:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: rephrase caveats and best practices

Browse Source
This commit is contained in:
Michael Brevard 2024-09-14 16:40:56 +03:00 committed by GitHub
parent fe9b2b96f5
commit 6f1757700c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/2.guide/2.directory-structure/1.components.md
View File

@ -263,16 +263,16 @@ For example, if you have a component named `IdleBar` and you'd like it to be del
Delayed hydration has many performance benefits, but in order to gain the most out of it, it's important to use it correctly:
1. Avoid delayed hydration components as much as possible for in-viewport content - delayed hydration is best for content that is not immediately available and requires some interaction to get to. If it is present on screen and is meant ot be available for use immediately, using it as a normal component would provide better performance and loading times. Use this feature sparingly to avoid hurting the user experience, as there are only very specific use cases that warrant delayed hydration for on-screen content.
1. Avoid delayed hydration components as much as possible for in-viewport content - delayed hydration is best for content that is not immediately available and requires some interaction to get to. If it is present on screen and is meant to be available for use immediately, using it as a normal component would provide better performance and loading times. Use this feature sparingly to avoid hurting the user experience, as there are only a few cases that warrant delayed hydration for on-screen content.
2. Use each hydration strategy for its intended use case - each hydration strategy has built-in optimizations specifically designed for that strategy's purpose. Using them incorrectly could hurt performance and user experience. Examples include:
- Using `LazyIf` for always/never hydrated components (via `:hydrate="true"`/`:hydrate="false"`) - you can use a regular component/`LazyNever` respectively, which would provide better performance for each use case. Keep `LazyIf` for components that could get hydrated, but might not get hydrated immediately (for example, following user interaction).
- Using `LazyIf` for always/never hydrated components (`:hydrate="true"`/`:hydrate="false"`) - you can use a regular component/`LazyNever` respectively, which would provide better performance for each use case. Keep `LazyIf` for components that could get hydrated, but might not get hydrated immediately.
- Using `LazyTime` as an alternative to `LazyIdle` - while both of these strategies share similarities, they are meant for different purposes. `LazyTime` is specifically designed to hydrate a component immediately after a certain amount of time has passed. `LazyIdle`, on the other side, is meant to provide a limit for the browser to handle the hydration whenever it's idle. If you use `LazyTime` for idle-based hydration, the component might get hydrated while other critical components are hydrated simultaneously, which would be different in behavior as the browser won't be idle, potentially slowing down the hydration of other important components in your page.
- Using `LazyTime` as an alternative to `LazyIdle` - while these strategies share similarities, they are meant for different purposes. `LazyTime` is specifically designed to hydrate a component immediately after a certain amount of time has passed. `LazyIdle`, on the other hand, is meant to provide a limit for the browser to handle the hydration whenever it's idle. If you use `LazyTime` for idle-based hydration, the component might get hydrated while other critical components are hydrated simultaneously, which would be different in behavior as the browser won't be idle, potentially slowing down the hydration of other important components in your page.
- \[ADVANCED\] Using only `LazyIf` to manually implement existing delayed hydration strategies - while a viable option, using only `LazyIf` in stead of relying on the built-in supported strategies could impact the overall memory consumption and performance.
For example, in stead of handling promises manually and setting a boolean indicator for when the promise was fulfilled, which would then get passed to `LazyIf`, using `LazyPromise` would handle the promise without requiring another ref, reducing the complexity and the amount of load Vue's reactivity system would need to handle and track.
- \[ADVANCED\] Using only `LazyIf` to manually implement existing hydration strategies - while an option, using only `LazyIf` in stead of relying on the built-in supported strategies could impact the overall memory consumption and performance.
For example, in stead of handling promises manually and setting a boolean indicator for when the promise was fulfilled, which would then get passed to `LazyIf`, using `LazyPromise` directly would handle without requiring another ref, reducing the complexity and the amount of work Vue's reactivity system would need to handle and track.
Always remember that while `LazyIf` allows for implementation of custom, highly-tailored hydration strategies, it should mainly be used when no built-in strategy matches your specific use case, due to the internal optimizations each existing hydration strategy has.
## Direct Imports