[DevTools] Visualize hydrated parts of an application

[AndrewKushnir]

Which @angular/* package(s) are relevant/related to the feature request?

devtools

Description

Currently there is no easy way to detect which parts of an application were hydrated and which parts were re-created. The proposal is to consider adding a support to Angular DevTools to inspect components and visually highlight:

• components that were hydrated
• components that skipped hydration (by adding the ngSkipHydration attribute)
• components that were serialized, but not yet hydrated (e.g. being lazy-loaded)
• components created from scratch

It'd be interesting to explore if we can visually separate them on a page once a certain mode is enabled in DevTools (see screen shot attached), so that it's easy to visually assess which parts of an application are hydrated. If it's problematic to annotate, we can may be add a flag into a component inspector panel to indicate it's hydration state.

We can also enable those extra flags and modes only when we detect that an application was server-side rendered.

// cc @AleksanderBodurri @dgp1130

[dgp1130]

Love this idea! I agree this is a great opportunity for DevTools to help with the hydration process. A couple questions about this:

• components that skipped hydration (by adding the ngSkipHydration attribute)
• components created from scratch

How are these two cases different? I was under the impression that ngSkipHydration basically meant "rerender from scratch". Is there more nuance to it?

• components that were serialized, but not yet hydrated (e.g. being lazy-loaded)

In what situation is component hydration delayed in the current implementation? I was under the impression hydration was a global process right now. Are you thinking about future improvements to hydration where components may hydrate individually (ex. partial hydration, islands)?

The main value I see for this feature is identifying which components are preventing a specific piece of UI from hydrating. It's easy to grep for ngSkipHydration in a codebase to identify all the components which aren't compatible, but DevTools can help devs identify a prioritized list of which components should be fixed first to have the most user impact (ex. fix the components on the home page first, since that has the highest traffic).

The bigger impact this could have is with an islands architecture where we can help devs understand how and when certain parts of their application hydrated (or didn't) so they can fix bugs or improve performance. For example, they might find that a large component gets hydrated because an insignificant part of it scrolled into the viewport. With an islands approach, hydration timing becomes a much more complicated process which can be harder for developers to intuit and DevTools can help a lot with that process.

[AndrewKushnir]

How are these two cases different? I was under the impression that ngSkipHydration basically meant "rerender from scratch". Is there more nuance to it?

Correct, in both cases a component would be created from scratch. Visualizing a component with the ngSkipHydration just gives additional information to developers that this component was intentionally excluded from hydration vs cases when a component that was purely created from scratch, which may or may not be intentional in an application.

In what situation is component hydration delayed in the current implementation? I was under the impression hydration was a global process right now.

The hydration is delayed for lazy-loaded routes: the process awaits JS chunks to be loaded and hydration resumes for a lazy-loaded component. This can also be achieved using a "manual" approach: a dynamic import + NgComponentOutlet (or ViewContainerRef.createComponent or createComponent).

Are you thinking about future improvements to hydration where components may hydrate individually (ex. partial hydration, islands)?

Yes, this feature would also be helpful for partial hydration and potential hydration for defer blocks.

The main value I see for this feature is identifying which components are preventing a specific piece of UI from hydrating. It's easy to grep for ngSkipHydration in a codebase to identify all the components which aren't compatible, but DevTools can help devs identify a prioritized list of which components should be fixed first to have the most user impact (ex. fix the components on the home page first, since that has the highest traffic).

There are also cases when hydration logic detects a mismatch between a client and a server and re-creates some views (and cleans up leftover DOM nodes). Such cases are currently "invisible" to developers and having a visualization would give a better sense of which portion of an application is hydrated.

The bigger impact this could have is with an islands architecture where we can help devs understand how and when certain parts of their application hydrated (or didn't) so they can fix bugs or improve performance. For example, they might find that a large component gets hydrated because an insignificant part of it scrolled into the viewport. With an islands approach, hydration timing becomes a much more complicated process which can be harder for developers to intuit and DevTools can help a lot with that process.

That also reminds me of defer blocks that we can also visualize in DevTools: visualize it's state, triggering conditions, whether prefetching was enabled, etc. Will create a separate ticket for this :)

[angular-automatic-lock-bot]

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.}