Player devtools RFC

[rafbcampos]

Player devtools RFC

Developer tool extensions are fundamental to ergonomics. Therefore, we must ensure that Player has a companion browser extension that allows it to be inspected and debugged while running in the user's application.

Current architecture

We leverage the Player plugins API, where the Player exposes tappable hooks, devtools plugins tap a subset of those and message the extension using window.postMessage.

When the extension starts, it injects a script tag containing the code to register the devtools-plugin.

The devtools-plugin taps on some of the Player hooks, starts messaging the devtools extension background page, and answers requests for more data or expression evaluation.

The extension leverages the devtools-common package, that exposes the redux store/reducer, types and messaging helper functions.

Finally, the devtools render the panel using the devtools-ds.

New requirements

Although the current implementation allows inspecting running Player instances, we want to expand its capabilities and fulfill those requirements:

• Support managed Player
• Handle multiple Player instances on the same page
• The user should be able to extend its features (e.g., adding new tabs)
• Multi-platform
• Implement manifest v3

Architecture changes proposal

With those requirements in mind, these are the changes we want to make to the devtools implementation:

• Add plugin support to the ManagedPlayer, so devtools plugins can also access its state.
• Instead of automatically adding plugins, we use the same approach for any other Player plugin, using the standard array of plugins.
• Instead of relying on the devtools extension to define the panels, the plugins set their UI using Player content (DSL).
• Slim down the devtools extension to only contain a Player instance and the script injection for proxying the messages between plugins and the extension.
• Create a Player Assets Plugin leveraging the devtools-ds components and use that in the devtools extension’s Player instance.
• Migrate to manifest v3.

Example flow:

• The user leverages a template for generating a devtools Player plugin.
• They tap into the Player hooks, and define the extension UI using DSL.
• The user adds their devtools plugins into the Player.config.plugins array.
• When the devtools starts, it initiates its Player instance and injects the script tag into the DOM.
• The devtools plugins tap into the player hooks and send the first Player content to the devtools Player.
• The devtools Player leverages the pub-sub plugin to message the devtools-plugin running in the inspected Player.

With those changes, we add support to Player inspection, allow the user to register any number of plugins, and let them define their UI.

Dependencies

• devtools-ds Player Assets plugin
• Player subscriber wrapper
• ManagedPlayer plugins

Performance

Every data processing / business logic runs into the plugins running into the inspected Player.

The devtools and its service worker, only handle messaging, subscription, data changes, and rendering the Player content sent by the plugins.

So having those processes running in the Player could potentially tank its performance.
We need to prevent that running while the extension is not active, so all devtools plugins need to have a runtime check for an environment variable, for example, and, if possible, adopt dynamic imports.

Inspiration

Vue devtools