-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strengthen the types for Bridge
events
#3838
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3838 +/- ##
==========================================
- Coverage 99.02% 99.02% -0.01%
==========================================
Files 211 211
Lines 7797 7796 -1
Branches 1757 1757
==========================================
- Hits 7721 7720 -1
Misses 76 76
Continue to review full report at Codecov.
|
545ce16
to
e6b39e5
Compare
I have created type definitions for all the event names that are sent across the different frames using various `Bridge`s. It is based on the previous `bridge-events.js`. I broke down the events in four sections based on the direction of the messages: * guest -> sidebar events * host -> sidebar events * sidebar -> guest/s events * sidebar -> host events For those events that didn't have a description I added one. This is more stringent and less verbose than the previous lookup system.
e6b39e5
to
1748ca4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The functional code changes look good. I found a few minor typos of event names in test descriptions.
The main feedback I have is regarding the comments in the bridge-events.d.ts
file. There are a few that are incorrect, some in obvious ways and others in more subtle ones, and others that reference implementation details of how the event is currently handled rather what the event means. For example when the guest sends "closeSidebar" to the sidebar app it is requesting that the sidebar be closed. How exactly the sidebar makes this happen is an implementation detail that might change in future. The most common issue I see though is where a comment restates the event and type name with the same words. Unless a comment is adding value (eg. by clarifying something about when the event is emitted, or why, or otherwise providing useful additional information), I would prefer to remove it.
|
||
/** | ||
* The Bridge service sets up a channel between frames and provides an events | ||
* API on top of it. | ||
* | ||
* @template {BridgeEvent} CallMethods - Names of methods that can be called (via {@link call}) | ||
* @template {BridgeEvent} OnMethods - Names of methods that can be handled (via {@link on}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per a Slack thread from last week, this is where defaults for template arguments might be useful. You could use [CallMethods=BridgeEvent]
and any use of Bridge
without arguments would use that. As it is, there are several places where no template arguments are specified and so it will default to any
.
I probably would have been inclined to just use string
as the base type here, to avoid coupling Bridge
to the specific events that it is used with in the client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. That seems useful, although presumably this would also work if the Bridge
instance has an annotation to specify the specific events that it uses?
src/types/bridge-events.d.ts
Outdated
@@ -0,0 +1,161 @@ | |||
/** | |||
* This module defines the set of global events that are dispatched across the | |||
* the bridge(s) between the sidebar-host and sidebar-guest(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change this to be a little more general. Something like: "This module defines the events that are sent between frames with different roles in the client (guest, host, sidebar)".
I expect that we will want to add additional channels in future, eg. guest <-> host or notebook <-> host and this change would avoid needing to update this comment each time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼
src/annotator/annotation-sync.js
Outdated
/** | ||
* @template {GuestToSidebarEvent} T | ||
* @template {SidebarToGuestEvent} U | ||
* @typedef {import('../shared/bridge').Bridge<T,U>} Bridge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we only ever use Bridge
with one pair of type arguments in this file, you could just make the type arguments part of this typedef. eg.
/**
* @typedef {import('../shared/bridge').Bridge<GuestToSidebarEvent, SidebarToGuestEvent>} SidebarBridge
*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼
* @typedef {import('../../types/bridge-events').SidebarToHostEvent} SidebarToHostEvent | ||
* @typedef {import('../../types/bridge-events').HostToSidebarEvent} HostToSidebarEvent | ||
* @typedef {import('../../types/bridge-events').SidebarToGuestEvent} SidebarToGuestEvent | ||
* @typedef {import('../../types/bridge-events').GuestToSidebarEvent} GuestToSidebarEvent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate how verbose this gets. There have been some discussions about better options in microsoft/TypeScript#22160 but I don't see a solution yet.
src/types/bridge-events.d.ts
Outdated
| 'profileRequested' | ||
|
||
/** | ||
* The sidebar inform the host to update the number of annotations in the partner site. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is ambiguity here about what "number of annotations" means. There is already a clearer explanation in https://h.readthedocs.io/projects/client/en/latest/publishers/host-page-integration/#cmdoption-arg-data-hypothesis-annotation-count which we could link to.
03fb10e
to
38cc9d7
Compare
@@ -11,8 +9,9 @@ const ANNOTATION_COUNT_ATTR = 'data-hypothesis-annotation-count'; | |||
* display annotation count. | |||
* @param {import('../shared/bridge').Bridge} bridge - Channel for host-sidebar communication |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue about any
type doesn't seem to happen in version 4.5:
https://www.staging-typescript.org/play?ts=4.5.0-dev.20211015&filetype=js#code/PQKhCgAIUgBAXApgWwA4BsCGTIG8DkAFouugPb4A++ARgJ6L4C+kAKlDLKpgE6bJ5WLTB2DgAxlgDOUyMjoBhabNxRI60BHXrO3PgNxDII7dDGnxmUgApMASlWmLZAHZSy6RADpyAc1t2ANxq6kzgYeDgmnDwdKiIePJKmDIAPEQk5PgAfCwgYuKuUvCQAJZu8Jgu4ogAjJAAvJAuiADucorK1kHg5cVVNbVeljYZpBQ9UWAxcQm4Scrp9Iy5ZhJFJX2V1YgATI3NbR3JMt3BWwN7w1bo1rQM+JOFFWUVlwDMBy3tCylSZ703jt3tdRsRxo9zkCaiCRrd7owekA
@@ -11,8 +9,9 @@ const ANNOTATION_COUNT_ATTR = 'data-hypothesis-annotation-count'; | |||
* display annotation count. | |||
* @param {import('../shared/bridge').Bridge} bridge - Channel for host-sidebar communication |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passing in the bridge here is not really the best separation of responsibilities. What I would suggest we do in future is make the sidebar responsible for listening for the message and instead put only the logic for updating the page elements (the contents of updateAnnotationCountElems here) in a function in a separate module.
I agree.
src/annotator/annotation-sync.js
Outdated
/** | ||
* @template {GuestToSidebarEvent} T | ||
* @template {SidebarToGuestEvent} U | ||
* @typedef {import('../shared/bridge').Bridge<T,U>} Bridge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼
src/types/bridge-events.d.ts
Outdated
@@ -0,0 +1,161 @@ | |||
/** | |||
* This module defines the set of global events that are dispatched across the | |||
* the bridge(s) between the sidebar-host and sidebar-guest(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏼
|
||
/** | ||
* The Bridge service sets up a channel between frames and provides an events | ||
* API on top of it. | ||
* | ||
* @template {BridgeEvent} CallMethods - Names of methods that can be called (via {@link call}) | ||
* @template {BridgeEvent} OnMethods - Names of methods that can be handled (via {@link on}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** | ||
* Channel for sidebar-guest communication. | ||
* | ||
* @type {Bridge<GuestToSidebarEvent,SidebarToGuestEvent>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
38cc9d7
to
eb4470d
Compare
I have accepted your changes regarding the descriptions of the events. Most of the descriptions were created previously. Some of the messages brings clarity to how the events flow. For example, I found it useful to know that the Some other events are difficult to explain even with the description: |
/** | ||
* The host informs the sidebar that a guest frame has been destroyed | ||
*/ | ||
| 'destroyFrame' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think frameDestroyed
would be clearer? (It sounds symmetric to sidebarOpened
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably. Some of the RPC calls defined in this module represent events that happened, without the caller necessarily expecting a specific response from the other frame. Other calls are commands that ask the receiving frame to do something specific (eg. openSidebar
). destroyFrame
does seem more of an event than a command.
eb4470d
to
0327737
Compare
src/types/bridge-events.d.ts
Outdated
@@ -76,7 +76,7 @@ export type SidebarToGuestEvent = | |||
| 'focusAnnotations' | |||
|
|||
/** | |||
* The sidebar is asking the guest(s) to get the document metadata. | |||
* The sidebar is asking the guest(s) the URL and other metadata about the document. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"the URL" => "for the URL"
Co-authored-by: Robert Knight <robertknight@gmail.com>
0327737
to
b36b8e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for your patience with this.
* @typedef {import('../types/annotator').AnnotationData} AnnotationData | ||
* @typedef {import('../types/annotator').Destroyable} Destroyable | ||
* @typedef {import('../types/bridge-events').GuestToSidebarEvent} GuestToSidebarEvent | ||
* @typedef {import('../types/bridge-events').SidebarToGuestEvent} SidebarToGuestEvent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these typedefs still needed given the change to the Bridge
typedef above?
|
||
/** | ||
* The Bridge service sets up a channel between frames and provides an events | ||
* API on top of it. | ||
* | ||
* @template {BridgeEvent} CallMethods - Names of methods that can be called (via {@link call}) | ||
* @template {BridgeEvent} OnMethods - Names of methods that can be handled (via {@link on}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. That seems useful, although presumably this would also work if the Bridge
instance has an annotation to specify the specific events that it uses?
I have created type definitions for all the event names that are sent
across the different frames using various
Bridge
s. It is based on theprevious
bridge-events.js
. I broke down the events in four sectionsbased on the direction of the messages:
For those events that didn't have a description I added one.
This is more stringent and less verbose than the previous lookup system.