Plugins in UnTab were just about providing results for the search index, and executing appropriate logic when a result was selected. While this served many use-cases, it started to feel like plugins needed more control over how they render the results and the other actions they'd support for each result. Thus, some UI-level control for the plugins seemed like the way to go.
How does this PR add the feature?
With UnTab Plugins UI, each plugin can now specify what they want to render for each result the plugin provides by simply defining it as a Svelte component :orange_heart:! With the power of Svelte components, these pieces of UI can have their own state, styles, and logic making plugins even more flexible. These Svelte components are only bundled with the content script bundle and are not a part of the background script bundle(as the UI part is irrelevant in the background script).
Another important piece of UI is interactivity. Interactivity is what allows buttons rendered in the UI to perform some action. This has been made possible through a basic event system where the UI calls an event with an appropriate name and arguments, and UnTab delegates this call to the handler specified in the plugins definition in the background script.
Example of how it works
Here's an example of how the new plugin UI works in the tabs search plugin. The plugin provides actions to pin/unpin tabs and close the tabs.
What if the plugin level UI becomes inconsistent over time?
Now that each plugin can specify its own CSS for the UI, there might be cases when styles of different plugins are inconsistent causing a bad UX overall. Also, the UI might start to get cluttered with buttons and text even more if it's not controlled. To control these problems, the following guidelines should be followed:
Plugins UI should be used only when it's very necessary.
A new set of simple UI components would be added like Buttons, that should be used to remain consistent with the overall look of UnTab. These UI components can be imported via @untab/plugins-ui. Currently, only a Button component is exported from this.
We should do very strict checks for PRs that add/update plugin level UI to be consistent with the rest of the extension.
Other changes in this PR
Updated sponsor link.
Add audio indicator for the tabs. Fixes #50.
Add buttons to pin/unpin and close tabs. Fixes #53.
Plugins definition file has been changed from src/background/plugins.js to src/plugins/index.js
Why Plugins UI?
Plugins in UnTab were just about providing results for the search index, and executing appropriate logic when a result was selected. While this served many use-cases, it started to feel like plugins needed more control over how they render the results and the other actions they'd support for each result. Thus, some UI-level control for the plugins seemed like the way to go.
How does this PR add the feature?
With UnTab Plugins UI, each plugin can now specify what they want to render for each result the plugin provides by simply defining it as a Svelte component :orange_heart:! With the power of Svelte components, these pieces of UI can have their own state, styles, and logic making plugins even more flexible. These Svelte components are only bundled with the content script bundle and are not a part of the background script bundle(as the UI part is irrelevant in the background script).
Another important piece of UI is interactivity. Interactivity is what allows buttons rendered in the UI to perform some action. This has been made possible through a basic event system where the UI calls an event with an appropriate name and arguments, and UnTab delegates this call to the handler specified in the plugins definition in the background script.
Example of how it works
Here's an example of how the new plugin UI works in the tabs search plugin. The plugin provides actions to pin/unpin tabs and close the tabs.
https://user-images.githubusercontent.com/21107799/118397502-ee452280-b671-11eb-90ee-030a42c67444.mp4
What if the plugin level UI becomes inconsistent over time?
Now that each plugin can specify its own CSS for the UI, there might be cases when styles of different plugins are inconsistent causing a bad UX overall. Also, the UI might start to get cluttered with buttons and text even more if it's not controlled. To control these problems, the following guidelines should be followed:
@untab/plugins-ui. Currently, only aButtoncomponent is exported from this.Other changes in this PR
src/background/plugins.jstosrc/plugins/index.js