onEvent<T extends Event>(event: CDPEvent<T>): void {
const sessionId = event.sessionId || '';
const session = this.#sessions.get(sessionId);
session?.target.dispatch(event as unknown as EventMessage);
}Technically we could get rid of `SessionRouter` alltogether in a follow-up:
The target base class subscribes to `onEvent` and then only dispatches where the session ID matches, i.e.
```
onEvent<T extends Event>(event: CDPEvent<T>): void {
if (event.sessionId === this.sessionId) this.dispatch(event)
}
```
The downside of that is that instead of getting exactly one session and dispatching on that, we call N `onEvent` observers, where N is the number of active sessions.
Not sure if that is a concern, but CDP is rather talkative. Wdyt?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
window.setTimeout(() => {can we use globalThis or nothing at all?
onEvent<T extends Event>(event: CDPEvent<T>): void {
const sessionId = event.sessionId || '';
const session = this.#sessions.get(sessionId);
session?.target.dispatch(event as unknown as EventMessage);
}Technically we could get rid of `SessionRouter` alltogether in a follow-up:
The target base class subscribes to `onEvent` and then only dispatches where the session ID matches, i.e.
```
onEvent<T extends Event>(event: CDPEvent<T>): void {
if (event.sessionId === this.sessionId) this.dispatch(event)
}```
The downside of that is that instead of getting exactly one session and dispatching on that, we call N `onEvent` observers, where N is the number of active sessions.
Not sure if that is a concern, but CDP is rather talkative. Wdyt?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
can we use globalThis or nothing at all?
Done
onEvent<T extends Event>(event: CDPEvent<T>): void {
const sessionId = event.sessionId || '';
const session = this.#sessions.get(sessionId);
session?.target.dispatch(event as unknown as EventMessage);
}Alex RudenkoTechnically we could get rid of `SessionRouter` alltogether in a follow-up:
The target base class subscribes to `onEvent` and then only dispatches where the session ID matches, i.e.
```
onEvent<T extends Event>(event: CDPEvent<T>): void {
if (event.sessionId === this.sessionId) this.dispatch(event)
}```
The downside of that is that instead of getting exactly one session and dispatching on that, we call N `onEvent` observers, where N is the number of active sessions.
Not sure if that is a concern, but CDP is rather talkative. Wdyt?
I'd say let's keep SessionRouter
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[protocol] Extract DevToolsCDPConnection class from SessionRouter
This CL is mostly a mechanical change that splits the existing
"SessionRouter" into a "connection part" and a "session management"
part.
R=alexr...@chromium.org
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |