mirror of
https://github.com/nuxt/nuxt.git
synced 2024-11-22 13:45:18 +00:00
docs: remove usage of unnecessary utils
This commit is contained in:
parent
bd831cac14
commit
c4123fa09f
@ -231,9 +231,9 @@ If you would like to override the default hydration triggers when dealing with d
|
|||||||
```vue [pages/index.vue]
|
```vue [pages/index.vue]
|
||||||
<template>
|
<template>
|
||||||
<div>
|
<div>
|
||||||
<LazyIdleMyComponent :hydrate="createIdleLoader(3000)" />
|
<LazyIdleMyComponent :hydrate="3000" />
|
||||||
<LazyVisibleMyComponent :hydrate="createVisibleLoader({threshold: 0.2})" />
|
<LazyVisibleMyComponent :hydrate="{threshold: 0.2}" />
|
||||||
<LazyEventMyComponent :hydrate="createEventLoader(['click','mouseover'])" />
|
<LazyEventMyComponent :hydrate="['click','mouseover']" />
|
||||||
<LazyMediaMyComponent hydrate="(max-width: 500px)" />
|
<LazyMediaMyComponent hydrate="(max-width: 500px)" />
|
||||||
<LazyIfMyComponent :hydrate="someCondition" />
|
<LazyIfMyComponent :hydrate="someCondition" />
|
||||||
<LazyTimeMyComponent :hydrate="3000" />
|
<LazyTimeMyComponent :hydrate="3000" />
|
||||||
@ -247,15 +247,6 @@ const promise = Promise.resolve(42)
|
|||||||
</script>
|
</script>
|
||||||
```
|
```
|
||||||
|
|
||||||
::read-more{to="/docs/api/utils/create-idle-loader"}
|
|
||||||
::
|
|
||||||
|
|
||||||
::read-more{to="/docs/api/utils/create-visible-loader"}
|
|
||||||
::
|
|
||||||
|
|
||||||
::read-more{to="/docs/api/utils/create-event-loader"}
|
|
||||||
::
|
|
||||||
|
|
||||||
::read-more{to="https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia"}
|
::read-more{to="https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia"}
|
||||||
Read more about using `LazyMedia` components and the accepted values.
|
Read more about using `LazyMedia` components and the accepted values.
|
||||||
::
|
::
|
||||||
@ -294,7 +285,7 @@ Delayed hydration has many performance benefits, but in order to gain the most o
|
|||||||
|
|
||||||
2. Delayed hydration with conditional rendering - when using `v-if` with delayed hydration components, note that `v-if` takes precedence. That means, the component will be hydrated when the `v-if` is truthy, as that will render exclusively on the client. If you need to render the component only when the condition is true, use a regular async component (`<LazyMyComponent />`) with a `v-if`. If you need it to hydrate when the condition is fulfilled, use a delayed hydration prefix with the `hydrate` prop.
|
2. Delayed hydration with conditional rendering - when using `v-if` with delayed hydration components, note that `v-if` takes precedence. That means, the component will be hydrated when the `v-if` is truthy, as that will render exclusively on the client. If you need to render the component only when the condition is true, use a regular async component (`<LazyMyComponent />`) with a `v-if`. If you need it to hydrate when the condition is fulfilled, use a delayed hydration prefix with the `hydrate` prop.
|
||||||
|
|
||||||
3. Delayed hydration with a shared state - when using multiple components (for example, in a `v-for`) with the same `v-model`, where some components might get hydrated before others (for example, progressively increasing media queries), if one of the components updates the model, note that it will trigger hydration for all components with that same model. That is because Vue's reactivity system triggers an update for all the dependencies that rely on that state, forcing hydration in the process. Props are unaffected by this. Try to avoid multiple components with the same model if that is not an intended side effect.
|
3. Delayed hydration with a shared state - when using multiple components (for example, in a `v-for`) with the same `v-model`, where some components might get hydrated before others (for example, progressively increasing media queries), if one of the components updates the model, note that it will trigger hydration for all components with that same model. That is because Vue's reactivity system triggers an update for all the parts of the app that depend on that state, forcing hydration in the process. Props are unaffected by this. Try to avoid multiple components with the same model if that is not an intended side effect.
|
||||||
|
|
||||||
4. 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:
|
4. 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:
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user