angular/devtools/projects/protocol
Doug Parker d639a8d1f9 refactor(devtools): display directive metadata from Wiz and ACX (#60475)
This updates the DevTools protocol to send Wiz/ACX metadata in addition to Angular metadata. Fortunately we don't need to worry about backwards compatibility here (`framework` is required for example), but the design roughly mirrors `DirectiveDebugMetadata` in `@angular/core`.

Beyond that, this is mostly plumbing through an extra data slice in the form of `props` provided by Wiz. An earlier version implemented `events` as their own slice as well, but was removed as there is currently no generic way to disambiguate events from any other form of callback passed in as a prop. Instead, event callbacks are visualized as functions under the "Props" category.

Working with `DirectiveMetadata` as a union is unfortunately a bit annoying since it requires casting to more specific `{Angular,Acx,Wiz}DirectiveMetadata` types for TS to allow property access, even when the properties are optional anyways.

This commit is mostly for adding Wiz, but does add a bit of ACX functionality which is not fully tested.

PR Close #60475
2025-03-27 20:26:12 +00:00
..
src refactor(devtools): display directive metadata from Wiz and ACX (#60475) 2025-03-27 20:26:12 +00:00
BUILD.bazel refactor(devtools): bring the angular devtools directory into the root bazel workspace 2022-01-26 16:35:31 -05:00
index.ts refactor: update license text to point to angular.dev (#57901) 2024-09-24 15:33:00 +02:00
README.md docs: update the Angular DevTools auto-generated READMEs (#45884) 2022-05-05 15:29:27 -07:00
tslint.json refactor(devtools): prepare codebase for migration to angular/angular repo 2021-11-21 20:23:18 -05:00

Angular DevTools Communication Protocol

Angular DevTools injects scripts in the user application page that interact with the framework debugging APIs. The injected scripts interact with the extension via message passing using a statically typed protocol.

This subdirectory contains:

  • Declaration of a statically typed message bus
  • Implementation of priority aware message bus
  • Interfaces that declare the messages exchanged between the extension and the page

We use the PriorityAwareMessageBus to ensure that certain messages have higher priority than others. Because of the asynchronous nature of the property exchange there's a risk that a message response may overwrite the result from a more recent response.

An example is:

  1. We request the state of the component tree
  2. We update the state
  3. We request the state of the properties of a particular component

We don't have guarantees that the response of 1. will arrive before the response of 3. Often the response of 1. is larger and might be delivered after 3. In such a case, it may contain the application state prior to the update and override the state update we received from 3.