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

No response

Description

Certain APIs are functionally "compound signals", meaning they compose multiple signal APIs. For example resource and linkedSignal both use multiple signal APIs under the hood.

Angular DevTools only sees the raw reactive graph, and so it displays the raw signal primitives rather than a single resource or linkedSignal. For example, I believe resource creates an effect for making the network request and then updates an internal signal. There's also multiple computeds for things like hasError.

This might be WAI from the perspective that it is more representative of what is actually happening. resource is not a single reactive value, and we should not mislead developers into thinking it is.

CC @JeanMeche @AleksanderBodurri @milomg

Proposed solution

There are two potential improvements we can make though:

1. Improve debugName so it is clear the composed signal primitives originate from a single user-defined resource or linkedSignal.
2. Create a visual "group" of signal nodes under a specific resource or linkedSignal.

I'm thinking that the graph would initially just treat a resource as a single reactive node and any dependency on value or hasError would point to that same node. But then when the user clicks on the node, they can expand it to show all the internal signal primitives (with appropriate names) and the dependency graph adjusts to depend on the specific internals it needs. This allows developers to get a high-level view up front while still supporting the more specific details when it becomes relevant to them.

Alternatives considered

1. We could hide signal internals altogether and only show resource / linkedSignal as a single reactive node, but this could be misleading to developers and potentially impede debugging efforts.
2. We could ignore the grouping solution and instead just focus on better naming, keeping the graph "honest", but this adds complexity where it often doesn't matter.