This is a hydration "issue".
The hydration only runs once the application becomes stable.
Invoking the request keeps the application unstable until the response arrives. Afaik, HttpRequests didn't contribute to stability prior to the experimental zoneless support.

Can this behavior be turned off on client side? I propose to disable ExperimentalPendingTasks for HttpClient on client side to fix this

This is not related to defer. We should review the hydration strategy when it comes to view containers that have different views on client and server.

@zip-fa looking at the video that you've shared and the code, Angular seems to work as expected.

The "Loading..." text that you see when you load the page is coming from the @placeholder block, which gets rendered on the server. After that, on the client, an application doesn't enter the "stable" state until HTTP request is in progress (in zone-based apps, HttpClient requests contribute to app stability). Once the request is complete and the app enters the "stable" state, Angular starts post-hydration cleanup, which removes unclaimed dehydrated views (removes the dehydrated view that contains the "Loading..." text).

@zip-fa looking at the video that you've shared and the code, Angular seems to work as expected.

The "Loading..." text that you see when you load the page is coming from the @placeholder block, which gets rendered on the server. After that, on the client, an application doesn't enter the "stable" state until HTTP request is in progress (in zone-based apps, HttpClient requests contribute to app stability). Once the request is complete and the app enters the "stable" state, Angular starts post-hydration cleanup, which removes unclaimed dehydrated views (removes the dehydrated view that contains the "Loading..." text).

I understand how it works, but this behavior slightly differs from the previous version: the HTTP client in v17 does not contribute to app stability, and blocks disappear instantly.
This is kinda breaking for me, when app changes its behaviour that much.

The only way to ‘fix this’ is to send all queries on the server side, so the client app will catch up with the response from the transfer state.

We did discuss this during triage, this not a defer blug but a hydration one. if/else block aren't handled correctly.

    @if (user()) {
      <div>foo</div>
    } @else {
      <div>bar</div>
    }

If <div>bar</div> is generated by the server, during hydration it doesn't replace it with the `

this not a defer blug but a hydration one. if/else block aren't handled correctly.
If

bar

is generated by the server, during hydration it doesn't replace it with the foo
generated client side and both are kept until the hydration cleanup.

@JeanMeche all unclaimed dehydrated views as removed during the post-hydration cleanup (that's the goal of the cleanup). There might be a period of time when both branches are visible on a page, but the post-hydration cleanup should remove one of the branches and it looks like it's happening (if I understand the comment correctly). Just want to confirm: do you see that the if-else block gets into the correct state, just not immediately?

Quick update: there were some hydration cleanup fixes landed in v18.2.0. @zip-fa could you please try to update your app and check if there were any changes in hydration behavior in your use-case?

Sure thing! Will try new version tomorrow early

The issue still persists on v18.2

Hey guys. Just saw tweet about i18n hydration. Is there any chances this gets fixed?😔
Sorry for being annoying

@zip-fa I've looked at provided repro and noticed the following hydration behavior on the client:

• an application hydrates initially as needed, finding the necessary DOM nodes
• the state of the user signal in the HomeCmp is different on the server and on the client
• as a result, in the generated HTML, we see the Loading... text from the @else block
• during hydration on the client, Angular detects that it needs to take a different path and render the @if part (since user info is available)
• as a result, we see both Loading... and user information on the screen
• once an application becomes stable (in our case - when HTTP call is completed) - Angular finds all unclaimed views and removes them (removing unclaimed DOM nodes)

The cleanup intentionally happens once an application becomes stable (e.g. when there is no pending work), but not immediately, since application state may change as a result of the pending work. Removing unclaimed views earlier may result in flickering on a page (for ex. if a user value would change multiple times during app initialization). The goal of the cleanup mechanism is to do a final sync between Angular's internal state and the state in the DOM. It's not recommended to rely on this cleanup for core application logic and the recommended approach is to have server and client representations as close as possible.

To make application behave similar on server & client side, we need to send requests inside SSR environment with user's JWT token. Currently, it's possible to do that in production build (intercept cookies via middleware on express side & provide JWT token as injection token), but it's not possible to do the same on local dev server. Is there a way to intercept request in dev environment (vite) with some kind of middleware @AndrewKushnir? If yes, this issue does not make sense

Is there a way to intercept request in dev environment (vite) with some kind of middleware

@zip-fa I believe it should be possible once PR angular/angular-cli#28463 lands (cc @alan-agius4 to confirm).

That is correct @AndrewKushnir.

Waiting to try v19 then 🙏🏻
Will update this issue if v19 is enough, thanks guys

On v19 this is no longer an issue - we can fully sync Client & Server rendering.

Please, solve this in version 18.2

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}