Skip to content

Contexts

Federico Brigante edited this page Feb 9, 2024 · 2 revisions

The extension is composed of several "apps" or contexts that are run independently and are interconnected via messaging or chrome.storage:

  • @/background/: A hidden page (or Service Worker in MV3) that we use as a source of truth and proxy for "global" requests
  • @/contentScript/: A script run on each open tab, which runs all the mods
  • @/pageEditor/: A React app that lets you see and compose bricks, it can be seen in the browser's dev tools
  • @/extensionConsole/: A React app that lets you configure the PixieBrix extension, it's the extension's "Options" page
  • @/sidebar/: A React app that can be opened in an iframe on the current tab (or in a dedicated sidePanel in MV3), its contents are managed by the content script
  • @/pageScript/: Like the content script, but it runs in the "main world", only used to collect data from JS frameworks, which is not possible from the content script. This is also managed by the content script

Since these are separate contexts, they live in distinct folders under src and they should not share code between each other. They can import from shared folders, but no external file should import from them.

ESLint

ESLint shows a warning when it finds these cross-boundary imports. If you find yourself using code from another context, you might choose one of these alternatives:

  • Keep both importing and imported modules in the same context (shared or @/one-of-the-above-contexts)
  • Use the Messenger if they are in the correct context, via messenger/api.js and messenger/registration.ts
  • Propose a pattern that we can use to share code between contexts, like we do via /messenger/ folders (e.g. we could implement @/sidebar/shared and treat it as an external folder)