Distinguish room state and timeline events when dealing with widgets #28681
Conversation
robintown
force-pushed
the
widget-state
branch
from
5ba7290 to
f5d96a5
Compare
| @@ -285,6 +291,17 @@ export class StopGapWidget extends EventEmitter { | |||
| this.messaging.on("capabilitiesNotified", () => this.emit("capabilitiesNotified")); | |||
| this.messaging.on(`action:${WidgetApiFromWidgetAction.OpenModalWidget}`, this.onOpenModal); | |||
|
|
|||
| // When widgets are listening to events, we need to make sure they're only | |||
| // receiving events for the right room | |||
| if (this.roomId === undefined) { | |||
There was a problem hiding this comment.
Just read through and worked out what's going on here: seems a bit excessive to send the entire room state through to an account widget whenever you switch rooms? I don't see any capability negotiation going on here so seems like this will happen whether the widget actually wants it or not. I guess it is what the spec technically implies but is anything actually going to use it?
There was a problem hiding this comment.
That's correct that matrix-widget-api is set up to re-sync the room state whenever an account widget encounters a new room. However, there is capability negotiation, and it will only read+push those state entries that match the widget's capabilities: https://github.com/matrix-org/matrix-widget-api/blob/61c45f78e09cafd3094c4a73892bd34be803bd98/src/ClientWidgetApi.ts#L1104
Is that already more along the lines of what you were expecting?
There was a problem hiding this comment.
ah, I missed that it was done at the event type level, so that makes more sense.
This change enables widgets to take advantage of the more reliable method of communicating room state over the widget API provided by this update to MSC2762.
Depends on matrix-org/matrix-widget-api#116