docs: reference pure conditional hydration as a LazyIf option

docs/2.guide/2.directory-structure/1.components.md

@@ -296,11 +296,11 @@ Delayed hydration has many performance benefits, but in order to gain the most o
 
 - 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 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.
+- 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. This could potentially interfere with the hydration of other important components, especially if they are higher priority to be hydrated.
 
 - \[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.
+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 it 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.
+Always remember that while `LazyIf` allows for implementation of custom, highly-tailored hydration strategies, it should mainly be used when either pure conditional hydration is required (for example, hydration of a component when a separate button is clicked), or when no built-in strategy matches your specific use case, due to the internal optimizations each existing hydration strategy has.
 
 ## Direct Imports