Webextension refactoring

[kirlat]

Ideas behind webextension refactoring (#128) were to implement the following architecture:

1. Background script intercepts all user interactions with extension icons and menus. It injects a content script into a target page (webextension only, in Safari content script is loaded automatically) and sends commands to activate/deactivate/open panel etc. according to user actions. This part of an app was not changed.
2. Content script, when injected into a target page, does the following:
   2.1 Starts a messenger service so that it can listen to messages from a background script (for webextension) or from a Safari app extension (for Safari)
   2.2 (optional) Notify a background that a messenger service is started and a content script is ready to listen to commands from a background.
   2.3 Depending on commands received, a content script creates, initializes, activates, or deactivates a UI controller (see https://github.com/alpheios-project/documentation/blob/master/development/app-architecture.md#state-control-methods). For other commands from background it might also run other methods of UI controller to open or close a panel or do other more specific actions.

That's it. We should keep it simple if possible, I think. We can think of a UI controller as a black box that a content script knows nothing about except how to create it properly and run a method that will correspond a command from a background (activate/deactivate/open/close panel etc.)

Do you agree with the approach proposed?

Does the content script in #128 matches this approach?

[irina060981]

My thoughts about modularity and independence:

UIController

I have faced with communicating with UIController several times from outstanding repos - lexical-tests (browser and node versions), inflection games, safari application front script. And everytime I had a problem that UIController is specified for a current set of tasks:

1. it creates all components - I couldn't use the UIController for simply communicating with adapters and LexicalQuery

2. it has all updated (morphology, definitions, inflections etc.) methods specificly updating vue-components

So it is not a tool for controlling the data retrieving from several sources and updating it somewhere - it is a part of whole extension and it couldn't be used (and partly used) with any other tools.

So for integrating it with something - I had two ways - copy everything I need and exclude everything I don't need (lexical-tests) and become a part of it (inflection games)

webextension and embedded-lib
From my experience they are used for a little different purposes:
Webextension is used for some external internet sites where you want to analyze words, inflections, translations and so on - it has activating, deactivating status, some common events.

As for embedded-lib it used on your own pages where you could have some specific tags, alignment - it is for your own embedded process and it seems to me - here we are going to give some opportunity for customizing and tuning. It could have some specefic events and some behaviour and we could extend it with the help of embedded-lib code.

As for PWA - I think you are more experienced with it.

So I think that events could have some prototypes (as you made for MouseDouble click) in components repo and UIController, but events should be initialized in extension or embedded-lib.
TabScript, State could have some specific in different browsers and emebeded targets.
So they could be enriched (new states, identifieres, additional parameters saved to Local Storage).

My opinion that we could have some base classes in some repo - for example components for all these browser, embeedded targets. And we could define some required behaviour there.
But the current implementatiuon with the ability to customize, init and upgrade should be accessible at the extention and embedded part.

So we could use such base classes in any application, UIController could be used as a central main controller for working with data and vizualizing using our components or some other components.

Your questions
I think that content process should handle with messaging service (if applicable), with events, with passing current implementations of adapters and may be in future with styles, and ability to attach additional components for visualization.

But as I wrote before I am not against your approach as it is a step to something better in future.
May be it is needed for optimization process.
And may be it is better to simplify now and make it more featureable in future :)

[balmas]

I think we have mostly implemented the refactoring we plan to do here now.