Component (Object) Architecture

[kirlat]

@balmas, @irina060981: Please review a proposition of an application architecture for our business classes: https://github.com/alpheios-project/documentation/blob/master/development/component-architecture.md.
I think it would be beneficial to us to standardize behavior of such components as UIController, ContentProcess, BackgroundProcess, etc.

Decided to assemble this piece and offer if for discussion before doing changes to the controller objects required to avoid preliminary data loading in Safari tabs, when content script is loaded to every tab automatically.

Please let me know your opinions. It would be great if we combine our experiences and ideas on this! Thanks!

[balmas]

I think this is a great start at defining architectural best practices for us to follow, and providing a template for business components.

I also really like the idea of isolating business logic from the display. I am becoming a little uneasy with the depth of our dependency on the Vue framework, and decoupling the business logic from the display logic will also help us to not become too dependent upon any one framework.

[irina060981]

I agree with Bridget - it is a great start for creating a higher-level application :)

I have some thoughts about this approach:

1. I really like the idea of separating Bussiness logic from Display components. According to Vue components we could divide code from there on the following groups:
   a) template part with sub-components, slots and different conditional rendering
   b) properties, methods and watchers that controlls rendering (render or not, what exactly to render)
   c) methods and properties that handles with current drawing, with html nodes, resizing, applying different styles
   d) methods and properties that inits events, changes properties for child components (and make them re-render)
   e) methods and properties for working with data, manipulating data, retrieving data - bussiness logic
   c) styles block and they can bw defined for the current template and for the child template

I think that if we want to become less Vue-dependable and be ready to be used with different frameworks - we should reduce the data in Vue components.

I think that we should use Vue components as a view templates that is only rendering input data, sending events and re-render on changing input data.
I think that it would be better to remove from methods direct handling with HTML nodes and move it to some Service classes or functions outside components.
This way we or someone else from community would be able to change Vue to any other templates or franework.

2. I think that we should put localization to some external outstanding library - as it could be used in different parts of the application/applications (for example inflection games could have its own localization, when we will decide to rework definitions/translations parts they could need its own localization, I think)

3. We have a mix with different styling in component, embedded-lib and inflection-games. I am adding styles for it through the link to components repo to be able to handle with changing fonts and color-schema. If we want to work with more complex styling and skin system, that could have more individual design , may be we should think about separating it from components ?

[kirlat]

Great ideas, Irina, thanks for sharing! Agree with every word you said.

Creating a Vue infrastructure we should also keep in mind its memory consumption. This probably is a topic for another discussion so I wont' go deep into that. A simple example could be an inflection table. Vue rendering is lazy, and Vue uses node patching. This means that if we have a rendered inflection table, it will stay in memory even if we switch to the other tab or work in a popup. It has many cells. If each cells has references to some other objects, those objects would stay in memory too. And those objects could refer to some other instances too. It could be even strong circular references. That all could eat up lots of memory! Should take those aspects into consideration when deciding on our architecture too.

For localization we have L10n, so we could probably add more functionality to it if needed and move it to become a separate library.

It's also so great that you mentioned styles! I think this is a very important part of an architecture (even though it might be orthogonal to the JS objects it does not matter). We probably need to have a different doc on styles too. I agree that it would probably make sense to separate styles from components (even though components, especially reusable ones, should probably have its own minimal styling to be of any value) but have no idea so far how it's best to be done. it's a complex topic as styles goes through a UI of several apps.

The big issue in styles is naming. We're using BEM approach, but that requires to identify and separate visual components form one another. Should pay attention to that.

We probably need to have at least two layers of styles: default ones and the ones that represent skins. We should also try to minimize rendered CSS if possible. Maybe we can peek at what large CSS frameworks (Bootstrap, UIkit, etc.) do here to borrow their expertise? Or maybe there is something even better than that?

Another interesting technology that might benefit our visual components are CSS modules: https://css-tricks.com/css-modules-part-1-need/. Maybe we should research this topic too when we can.

[irina060981]

I am happy, that you liked these ideas :)
About Css Modules - from my point of view the Vue approach is better than CSS Modules described in the article.
All sytles in components could be created with scoped parameter and it would be rendered this way:

1. everytime you compile the Vue application - it creates an additional data parameter to every html tag (for components that has scoped styles parameter)
2. this data parameter is added to styles definitions
   For example,
   

This parameter re-inits each compiling.

[irina060981]

From my experience our approach to styling is close to used in Bootstrap:

1. there are all styles divided to separate files (less/scss) - some of them are core and should be used in any build and some of them are specific to used components. So when you want to use some custom build - you should decide and those you neeed.

2. There is a constant parameters files (colors, base-fonts, base layout sizes)

3. All files are used with these parameters.

4. So if you want to apply some skin - you are creating an additional skin class and change constants according to the skin.

In our case It seems to me that we couldn't really optimize styles amount - as they should be compiled before and append through the only css file to head. And BEM approach makes additional amount of memory that needs to save our styles (because of long classes name).
For our project that uses really not so much html markup we have 287Kb styles only in components repo.

[kirlat]

Moved styles-related discussion to #4 to keep this issue focused on component (object) architecture.

[kirlat]

@balmas, @irina060981! Please review a proposal to update a business components architecture: https://github.com/alpheios-project/documentation/blob/master/development/app-architecture.md (described in Business components architecture section). Thanks!

[irina060981]

@kirlat , I have read your deatiled description only now (I am sorry, it seems I have missed an email about this update).
As I have written my thoughts in other issues about UIController
(
alpheios-project/webextension#130 (comment)
alpheios-project/components#257 (comment)
)

I think that you are doing a great job describing all here with detailed schemas!
I have only a couple of question:

1. why did you decide to include all adapters as singletone (now they have different ways to be added) ? What are the advantages of this type of connecting? (i have used different ways in my experience and have no idea what is the best one)

2. do we consider to use UIController only according to web page with our some Vue components ? (and it is natural from UIController title) For example for inflection games, lexical tests - should I create something similiar to UIController but in separate repo?

[kirlat]

@irina060981! Thank you so much for your detailed answers. They're great pieces of information and super helpful. I would like to mull over it a little.

I will try to answer more simple questions here 😄.

Will start from the second one about a UI controller. I should probably travel back in time to explain it. When this project started, we were not using Vue.js yet. All visual components (and inflection tables as the most complex of them) where generating their HTML code manually. So we had components that rendered HTML of inflection tables, panel, popup. Those, in terms of Vue and similar frameworks where presentation components: the ones whose main purpose was to display something. However, we needed some controller to tie them up together. That's why UI controller was created. So if someone selected a different inflection table from a drop down, UI controller would intercept that and send a command to inflection tables library to generate and display a different table. Thus, the UI controller is something what Vuex is to Vue presentational components. Now we migrated all our presentational components into Vue SFC format, but UI controller still remained what it was. But I think once we start using Vuex, most of it's functionality, if not all, would go to Vuex. So the UI controller would not exist as a "supercontroller" what it currently is.

Also, I want to note that the purpose of a UI controller was user input coordination only, If one wants to get lexical data via a lexical query, he/she should not use UI controller at all. That's what queries are for: to get information from one or several sources. So if one wants some lexical data, there is no need for a use UI controller at all. One should start a new LexicalQuery, and it should return all lexical data obtained. If somebody wants something like annotations, he/she should use AnnotationQuery and so on. One specialized query per type of data. That was the idea. Now, unfortunately, it's not so pure: LexicalQuery is coupled heavily with a UI controller as it calls multiple methods of it in the process. But I think we could (and should) fix that.

If for your tasks you don't need any visual data display, then you don't need an instance of a UI Controller at all. You need to use Queries to get the data you need and that's it.

If you want to display some different UI components in some different way, you probably need a different UI controller for that. It can inherit from a base UI controller component, or we could use composition where a UI controller would be composed of different modules instead. But maybe we would Vuex to replace a UI controller functionality.

That's the idea. Implementation may differ from what's described, but it doesn't mean we couldn't fix it.

The answer to your first question about singletons lies in area of ownership and memory management. When something that exists in memory for a long time (like a UI controller) owns some other object that occupy a sizeable chunk of memory, that other object cannot be garbage collected. My idea was that instead of holding some adapter for a long time, it would make sense to get a link to it only when we need it (inside of a lexical query, for example) and then release it (when lexical query is done) so it can be garbage collected. And singleton pattern, as I thought, would simplify reference management. If we have a reference to a morphAdapater, for example, and we store a reference to it in a UI controller and then we need to pass it to a LexicalQuery, we have to pass it as an argument. That could become cumbersome when we need to pass several references this way. It might be beneficial just to call let morpAdpater = MorpAdapter.instance() inside a LexicalQuery and then do let morphAdapter = null when query is done so the adapter can be garbage collected. So it is, on my opinion, simpler and may reduce memory consumption. But I think it can not work in all scenarios, so I don't think all those adapters shall always be singletons. There can be other considerations: if an adapter is expensive to initialize, we might initialize it once and hold for the whole lifetime of a UI controller. We should find a right approach for each particular case. So we would probably use both approaches (reference and singleton).

What do you think? Does it make sense?

[irina060981]

@kirlat, thank you for the history explanation - it is really interesting for me as for a newby :)
About using Lexical Query instead of UIController - it is deeply depended with UIController not only because cross-update methods,
it uses options from Storage - so these options should be got using UIController - as it has not so simple workflow for that,
it uses localization from UIController
it has a UIController as its own property
:) So they are really couldn't be used one without another :)

I understand (thank you for the story) that it is only a step on a upgrading/developing way :)

About instances - it is not really clear for me - because - you are to pass the whole class instead of passing the object, and it will store almost the same structure for the class in the memory. May be there will be some benefit from not storing current values.

I think that we could reach some benefits if use adapters the same way as axios
We import the adapter as module and init it inside the for example lexical query with some configuration stored in for example UIController or somewhere else.

Then all instance with the data of the whole class will be used inside closure and will be cleared after LexicalQuery object destroyed.
And we will be able to save the configuration and some customizable ability.
What do you think about this variant?