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
|
||
|---|---|---|
| .. | ||
| src | ||
| BUILD.bazel | ||
| index.ts | ||
| README.md | ||
| tslint.json | ||
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:
- We request the state of the component tree
- We update the state
- 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.