Skip to content

C
coopwire-hypothesis
Switch branch/tag
  1. 18 Jan, 2022 7 commits
    • Robert Knight's avatar
      Add test for calling `on` after `connect` · 3a354558
      Robert Knight authored
      3a354558
    • Robert Knight's avatar
      Combine Bridge and PortRPC classes · bb510f43
      Robert Knight authored 
      Reduce the number of layers involved in inter-frame communication by combining
the Bridge and PortRPC classes. PortRPC still only supports sending requests to
a single port, but now has an API that is more like the Bridge class, where
construction of the class, registering of RPC method handlers and connecting to
a MessagePort are separate steps. This separation is convenient because it
allows the RPC client to be set up before the MessagePort retrieval process,
which is async in non-host frames, has completed.

Existing uses of Bridge have been replaced either with a single PortRPC
instance, for 1:1 connections between frames, or an array of PortRPC
instances for 1:N connections between the sidebar/host and guest frames.
Migrating to an array for 1:N connections paves the way to sending certain
requests only to specific guests, whereas they are currently sent to _all_
guests.

Bridge's `call` method had logic for gathering results from multiple guests,
timing out and disconnecting clients in the event of an error.  This logic was
inappropriate in various ways and has not been re-implemented in PortRPC.

 - The timeout value was hardcoded at 1000ms for all calls. This may be too
   short depending on what the call does or what code is executing in the
   destination frame.
 - Disconnecting clients in the event of _any_ error, whether with the
   connection or an error on the client end in handling the call, doesn't make sense.
 - The `call` method returned a single Promise, so an error from any client
   would replace successful results from other clients. Also the client would
   have to wait until the results from all callers was available before sending
   a response.
 - The `call` method always passed a callback function to `PortRPC.call`,
   resulting in PortRPC always sending a response message back over the message
   channel, even when the code calling `bridge.call` did not use the response.
   Currently _no_ calls to `bridge.call` used the response, so this was just
   wasted traffic.

The changes in detail are:

 1. Change the PortRPC API to be more like Bridge, where an instance is
    constructed, RPC handlers are added via `on` and the client is then
    connected to a port via `connect`.

 2. Replace use of Bridge with either a single PortRPC or array of PortRPCs in
    the `Guest`, `Sidebar` and `FrameSyncService` classes.

    This required changes in various tests to simulate a guest frame connecting
    before testing that a particular event resulted in an RPC call being made to
    a guest frame.

 3. Rename `bridge-events.d.ts` => `port-rpc-events.d.ts` to match (2)

 4. Remove the `Bridge` class, its tests and the PortRPC-Bridge integration
    tests, as they are now unused.

Two existing issues were identified in this work but are not yet resolved:

 1. `FrameSyncService` does not tear down the PortRPC client for a guest when
     the guest frame disconnects.
 2. If a cross-frame RPC call is attempted before the async port discovery has
    completed, nothing happens. It will probably make sense to queue calls
    similar to how MessagePort queues messages.
      bb510f43
    • Eduardo's avatar
      Apply suggestions from code review · f709339f
      Eduardo authored 
      Co-authored-by: 's avatarRobert Knight <robertknight@gmail.com>
      f709339f
    • Eduardo Sanz García's avatar
      Move scroll and resize listeners to their own service · 2ae809c9
      Eduardo Sanz García authored 
      This is a step towards making the bucket bar works for a `guest` frame
that is not in the `host` frame. When that's the case the observation of
scrolling and resize can't happen in the `host` frame.

A new service has been created, `BucketService`. The service is
instantiated only in the `guest` frame that contains the main
annotatable content. The service observes changes in the elements that
could impact the relative position of the anchors relative to the
viewport. If these changes are detected, as well as addition or deletion
of anchors, it sends the `anchorsChanged` RPC event to the `host` frame
so that the positions can be recalculated. As a result of the new
service the `BucketBar` has been simplified.
      2ae809c9
    • dependabot[bot]'s avatar
      Bump eslint from 8.6.0 to 8.7.0 · 96f25627
      dependabot[bot] authored 
      Bumps [eslint](https://github.com/eslint/eslint) from 8.6.0 to 8.7.0.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Changelog](https://github.com/eslint/eslint/blob/main/CHANGELOG.md)
- [Commits](https://github.com/eslint/eslint/compare/v8.6.0...v8.7.0)

---
updated-dependencies:
- dependency-name: eslint
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: 's avatardependabot[bot] <support@github.com>
      96f25627
    • Robert Knight's avatar
      Clarify references to guest frames in FrameSyncService · e8318a82
      Robert Knight authored
      e8318a82
    • Robert Knight's avatar
      Remove `onConnect` method from Bridge · c72257a9
      Robert Knight authored 
      Simplify the Bridge class by removing the `onConnect` API and replacing
current calls with alternative approaches.

The `onConnect` method was a way to register a callback that would be invoked
after a test RPC call over a newly-connected channel succeeded.

The purpose of this method was not that clear however and its existence
suggested that it is necessary to wait for the callback to be invoked before
making RPC requests on the new channel. This is not the case, as the underlying
transport buffers messages until the receiver is ready to consume them. Therefore
RPC requests can be made as soon as `createChannel` returns.

The current uses of `onConnect` were replaced as follows:

 1. The host frame used it to be notified when the sidebar application has
    loaded. This has been replaced with an explicit `ready` RPC call.

 2. The sidebar waited for this callback before querying metadata for a
    newly-connected guest. It now sends a metadata query to the guest
    immediately when it receives the guest port from the host frame. This saves
    an unnecessary round-trip between the host and guest. In future we can
    optimize metadata querying more by having the guest _push_ metadata to
    the sidebar rather than waiting for the sidebar to query it.
      c72257a9
  3. 17 Jan, 2022 10 commits
  5. 10 Jan, 2022 7 commits
  7. 07 Jan, 2022 5 commits
  9. 06 Jan, 2022 1 commit
  11. 03 Jan, 2022 10 commits