x before its official release. x. Most of the issues in here are indeed just little chores, so that means to me that we're probably getting pretty close to the release, which is awesome. However, this particular issue right here really caught my eye.
It's a brand new feature that they have labeled delayed hydration. What is this? Well, let me zoom in just a little bit and we can read a little bit more. Basically, this is a performance feature that gives you the developer complete control over when a component hydrates.
With this feature, you could specify that the browser only download and execute the JavaScript code associated with a component when it's actually visible within the viewport, or when the browser is idle and is not doing any other important work. You could hydrate certain components on specific events, on specific timeouts, on some kind of promised fulfillment, maybe even never hydrated at all. or you could even provide some general purpose condition, which could be used to implement custom highly specific triggers. If you're familiar with the view lazy hydration package that Marcus Overlander put out quite a number of years ago now and was super handy to me in Nux 2, I'm not sure if it works with Nux 3 or not, but this is essentially the same kind of thing.
In this case, Lazy Hydrate was a functional component where you provided some component in its default slot, and then it would just hydrate based on the prop that you gave to Lazy Hydrate. So in this case, never, and in this next case, only when visible. Now, I haven't dug into the exact syntax for this particular baked-in feature. However, I know it's going to be great.
14.