-
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
Adoption of PortProvider
and PortFinder
#3903
Conversation
cffd395
to
c6e48bf
Compare
f0d7c4d
to
cacceeb
Compare
Codecov Report
@@ Coverage Diff @@
## master #3903 +/- ##
==========================================
- Coverage 99.00% 99.00% -0.01%
==========================================
Files 214 214
Lines 8015 8011 -4
Branches 1896 1894 -2
==========================================
- Hits 7935 7931 -4
Misses 80 80
Continue to review full report at Codecov.
|
cacceeb
to
92b6ca3
Compare
PortProvider
and PortFinder
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 have had an initial look over this. Functionally everything seems to work as desired. Aside from the minor comments, a few high level issues I raised:
- Where we put the logic that determines where the host frame is, in relation to the current frame. Related to this, the behavior of the
Guest
constructor changes significantly depending on theconfig.subFrameIdentifier
property, but that's not captured at all in docs or argument types. - Where the
PortProvider
is constructed. This currently happens in theSidebar
class, but perhaps it should live at a higher level (ie. the entry point) since it is so central to how the application works and should be easy to find. - I raised a hazard regarding stubbing of
window.parent.postMessage
in guests. That doesn't break anything in the test runner that I can see at present, but I can see a risk of that happening in future.
8ce62d7
to
2a730d1
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.
@robertknight, I have added all your suggestions on a second commit.
@@ -178,7 +178,7 @@ export class PortProvider { | |||
/** | |||
* Returns the `host` port from the `sidebar-host` channel. | |||
*/ | |||
get sidebarPort() { |
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 realised it had the wrong port name.
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.
You'll need to change this if other other host-side ports can be retrieved in future, such as a host <-> notebook port. I think something like hostPortFor('sidebar')
might be a good API even if the 'sidebar' argument is currently redundant, as it makes it clearer to a reader what is at the other end of the port.
src/shared/port-provider.js
Outdated
} | ||
} | ||
|
||
/** | ||
* @param {'hostPortRequest'} eventName | ||
* @param {'hostFrameRequest'} eventName |
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 believe this name matches the PortFinder#discover
, which tries to discover a frame. The name of the port is not as relevant as that the host
frame has been discovered.
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 had some suggestions regarding PortProvider
APIs and a few JSDoc comments. Otherwise the changes look good to me.
@@ -178,7 +178,7 @@ export class PortProvider { | |||
/** | |||
* Returns the `host` port from the `sidebar-host` channel. | |||
*/ | |||
get sidebarPort() { |
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.
You'll need to change this if other other host-side ports can be retrieved in future, such as a host <-> notebook port. I think something like hostPortFor('sidebar')
might be a good API even if the 'sidebar' argument is currently redundant, as it makes it clearer to a reader what is at the other end of the port.
@@ -226,7 +234,7 @@ export class FrameSyncService { | |||
/** | |||
* Connect to the host frame and guest frame(s) in the current browser tab. | |||
*/ | |||
connect() { | |||
async connect() { |
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.
Because connect
is now async, any failures will no longer trigger the catch
block at the bottom of src/sidebar/index.js
and thus the exception won't be reported via reportLaunchError
. I think fixing that would be too big of a change for this PR, but we should address it in future.
This adoption simplifies the discovery of frames. I did a little bit of clean-up in the tests: rearranged a few variables alphabetically, and delete unneeded lines and variables.
7e200c7
to
a461010
Compare
In future PR, `Guest` will contain two bridges (like `FrameSync`). Naming them by the destination frame will help identify the purpose of it. It seems that the convention for this `Bridge`s is to contain the word `RPC` to indicate that it is a remote (inter-frame) procedure.
a461010
to
75d7e43
Compare
This adoption simplifies the discovery of frames.
I did a little bit of clean-up in the tests: rearranged a few variables
alphabetically, and delete unneeded lines and variables.
Closes #3533