Use case A:
You have a list of product items on a list page on an ecommerce platform. You don't know if a user will ever see or interact with that product. So you put it underneath a defer block with hydrate syntax for it to fetch and hydrate only once it's been interacted with, reducing your initial bundle size. In this case, the product still gets rendered, but the code for the component doesn't get fetched until it's needed.

Use case B:
You have a blog post that is mostly static content. You can use ahydrate never condition to avoid shipping any javascript for that post component.

Use case C:
You have a large component above the fold, like your header or carousel. Your heatmaps show that very few people click on those. So you can put them behind a hydrate trigger to render them, but avoid shipping the content until someone interacts with it.

@thePunderWoman maybe deferred hydration is better name? It implies it's related to defer blocks......

We discussed deferred hydration as a potential name. It's possible to perform full-app hydration on idle, which makes it deferred, but not necessarily incremental. Calling it "incremental deferred hydration" will be accurate, but also too long without bringing too much value.

Incremental Hydration and Partial Hydration both seems natural and reflects exactly what the feature is about.

mutually exclusive is a good way to put it, yes. Hopefully that's clear and makes sense. We are also utilizing event replay for the content in the hydrate blocks. So if a user interacts with that content, the interaction will not be lost.

So I understand that the 'Hydrate' syntax makes the 'dom' structure render without hydration. But what happens when I use@Placeholder or@Placeholder+@loader together with this function? Does that mean they will be skipped on the server side?

So I understand that the 'Hydrate' syntax makes the 'dom' structure render without hydration. But what happens when I use@Placeholder or@Placeholder+@loader together with this function? Does that mean they will be skipped on the server side?

This is correct. In the SSR / hydrate case, your defer main template contentIS your new placeholder. The@placeholder and@loading templates you provide will be used in the client side rendering cases, just like they do today.

Ok, but if I don't use the word 'Hydrate', the placeholder will come from the server. I just want to be sure.

@zygarios If you don't use the wordhydrate, things will behave exactly as they do now with SSR. The@placeholder block gets rendered on the server and is hydrated eagerly with the rest of the full application.

I'd adviseidleTimeout or something else that makes clear it's a timeout.idle(2000), with no context, may not convey enough information about the behaviour

@e-oz This is definitely more of a feature request for@defer as a whole, rather than anything specific to this hydration RFC. Could you create a issue / feature request with this instead?

Could you create a issue / feature request with this instead?

Sure!#57814

This is additional syntax for@defer blocks. So@placeholder,@loading, and@error are all supported. However they wouldn't apply for hydrate cases as the placeholder is the server rendered content, and there's no need to display loading, as the actual content is already present. They'd still work as they normally would in a CSR situation though.

When I read about this RFC, the first use case I imagined could be a potential win was routerLink handling in dehydratated content; I'd love this

As a quick follow up, the only real concern around routerLinks in dehydrated code would be when routerLinks exist inhydrate never blocks. Any interaction with a routerLink in any other case will trigger hydration, and that click will get replayed, resulting in the expected client side navigation. In ahydrate never case, as long as routerLink is used on an anchor tag, it would navigate, but as a hard navigation. Any other use of routerLink, though, wouldn't do anything inside ahydrate never block.

Exactly, that is why it'd be wonderful that in hydrate never it'd still trigger an SPA navigation without needing to hydrate. For simple use cases shouldn't be that complex. The event of a hard navigation could be intercepted in the root element, the url parsed, and router execution triggered. It's nice to see that it may be explored 😃. This way only m truly interactive regions would need to be hydrated,

@thePunderWoman One additional question on this statement:

Any interaction with a routerLink in any other case will trigger hydration, and that click will get replayed, resulting in the expected client side navigation.

routerLink implementation doesevent.preventDefault(), which cancels browser's hard navigation, and does a SPA navigation. When the component is not yet hydrated, what does exactly happen? Does the event replay library also callevent.preventDefault()? If not, the browser will synchronously execute a hard navigation, and hydration will just be lost. Asking without actually testing it... 😅 Thanks for helping me understand the deep waters of hydration 💧 (pun intended).

@samuelfernandez The event replay behavior makes sure the original click is not a hard navigation in this case. So it will behave as you would want, with the replay and the client side navigation.

@e-oz Soprefetch just makes sure your chunk is prefetched, but your defer block still renders what's in the@Placeholder block until triggered.hydrate is a signal to the server side that you'd like to render your defer block main template on the server.hydrate changes what is rendered on the server server side, affecting what the user sees on first render.prefetch specifies how early the chunk is fetched on the client side. Does that help clarify?

Sure. I meant thatprefetch is designed to run before the actual execution, just likehydrate. But I do realize thathydrate does much more thanprefetch. My point was - maybeprefetch already points to things we would like tohydrate. But it's merely an assumption; I wasn’t trying to say anything against the idea itself. The idea is awesome, and I hope to try it as soon as possible - before February 30, 2025. 😎

1. Yes there is. The reason being that the rest of the triggers areevent based andhydrate when isexpression based.Event based triggers do not rely on logic in the component to trigger and can have shared logic for all of the instances across your page.Expressions rely on logic in your component that contains the defer block. We cannot evaluate an expression that does not exist yet. If the immediate parent is hydrated, theexpression will be present and can be evaluated. If the parent is dehydrated, that logic hasn't yet been fetched.

2. Your expectation is correct and how things should behave on the initial SSR page load. Subsequent page loads would result in that logic being fetched, as subsequent page loads are client side rendered.

3. We did consider components as hydration boundaries and also defer boundaries, but since the entire component is not what is being deferred, this sort of syntax wouldn't work, as you can have multiple defer blocks in a given component template. We're also actively trying to reduce the amount of configuration in the component decorator. So this would be moving us in the opposite direction of that goal.

Yes, I would assume Client Side Render could still use a@placeholder.

@brandonroberts but since it's called@hydrate, which is specifically a server side rendered behavior, does that not send a confusing message? You can't hydrate client side rendered content.

Ok, I misunderstood the connection with CSR then. I was thinking of this in terms of shorthand syntax that works in both scenarios.

I thought if you happen to use@defer and hydrate without server-side rendering the page first, it would fall back to just being deferrable. Will it throw an error or warning if so?

It wouldn't make sense to use defer and hydrate conditions without SSR. Similarly it wouldn't make sense to use@hydrate in that scenario. What I'm getting at is these hydrate conditions apply to SSRed content, which means first load. It may be unclear to folks that they're affecting CSR situations when using@hydrate when by its naturehydration is an SSR thing.@defer with hydrate conditions may be clearer to people that it serves both cases.

I agree that@defer is more appropriate. In case of partial hydration we are in fact deferring the hydration to a more appropriate time.

Could you please provide an example where you have a server-side rendered (SSR) page, and you'd like to hydrate a child component based on a specific trigger? Additionally, in the case where the user navigates to the same page via client-side navigation, you want that component to be defer-loaded using a different trigger. I almost always ended up using the same trigger for both cases.

A heavy datepicker that users don't often interact with.
If SSRed, I'd want it to be hydrated on interaction as it is unnecessary to hydrate it if it's not used.
On the other hand, if it's CSRed, I would want to replace my placeholder on idle because the date it displays is relatively useful to the user even though they do not interact with it.

That’s an interesting use case, and while you might have specific requirements, I would generally avoid server-side rendering a datepicker. When a datepicker is rendered on the server, it might display the server's date and time, which could be confusing or inaccurate for users in different time zones. This could lead to errors if the displayed date doesn't match the user's local time. So, if you do SSR a datepicker, it’s crucial to hydrate it as soon as possible or during idle time to ensure the correct date is shown. However, I understand you may have unique needs.

I think about it alot. walking around not trusting anyone

Yes there is a reason we didn't makehydrate on idle the default. People may not want some blocks to use partial hydration, and if we have it default when omitted, there's no way to avoid it. We have considered a shorthand, though, which would be something like@defer(on idle; hydrate). Where essentially just sayinghydrate with no trigger indicates you want to use the same trigger as the regular defer. You could omiton idle in that case and it would just be@defer(hydrate). How do you feel about that concept?

@defer block doing hydrate on idle by default feels more natural to me 😀

💯 for@defer(hydrate) shorthand.

People may not want some blocks to use partial hydration, and if we have it default when omitted, there's no way to avoid it.

There could be an instruction to opt-out from hydration, even though it will be tough to name 😅:hydrate disabled? it's going to be hard to find something that doesn't get confusing withhydrate never

Perhaps something like:

@defer (on idle; server placeholder) {...}

it doesn't need to be ahydrate condition specifically...

I am not sure whatserver placeholder would do in this case?

Being able to create reusable policies is definitely a thing we've considered. So if there's enough interest, it could be a future feature add.

That concept is essentially what resumability is. We love this idea, but it is quite a bit more challenging and complicated to get to this point. Dependency injection, data dependencies, and a number of other complications all factor into making this a workable feature with Angular. We think incremental hydration is a step towards that possibility in the future. So stay tuned.

Ideally you would updatengx-image-cropper to useafterRender hooks to make them safe for hydration. In lieu of that, if you use a hydrate trigger, I'd go withngSkipHydration on this element, as it's no longer client side rendered. Alternatively if this is a component that only ever has the image cropper in it, just skip using a hydrate trigger and leave it like it is, as that's not going to change behavior.

Sorry. RFC conversations don't typically discuss expected timelines.