docs: remove usage of unnecessary utils

This commit is contained in:
Michael Brevard 2024-10-09 10:28:32 +03:00 committed by GitHub
parent bd831cac14
commit c4123fa09f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -231,9 +231,9 @@ If you would like to override the default hydration triggers when dealing with d
```vue [pages/index.vue]
<template>
<div>
<LazyIdleMyComponent :hydrate="createIdleLoader(3000)" />
<LazyVisibleMyComponent :hydrate="createVisibleLoader({threshold: 0.2})" />
<LazyEventMyComponent :hydrate="createEventLoader(['click','mouseover'])" />
<LazyIdleMyComponent :hydrate="3000" />
<LazyVisibleMyComponent :hydrate="{threshold: 0.2}" />
<LazyEventMyComponent :hydrate="['click','mouseover']" />
<LazyMediaMyComponent hydrate="(max-width: 500px)" />
<LazyIfMyComponent :hydrate="someCondition" />
<LazyTimeMyComponent :hydrate="3000" />
@ -247,15 +247,6 @@ const promise = Promise.resolve(42)
</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 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.
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: