Create bases for Adblock Plus UI Modularization

[saroyanm]

Background

We are using different components in Options page, but we are only separating them Either by comments, or there is no separation at all, in order to make the development and contribution to the options page more easy it will make sense to use modular approach of Separating relevant components into the module, this might require of another build step introduction in order to bundle things together

What to change

Implement tickets below:

Ticket	Status	Resolution	Summary	Component	Owner
#6303	closed	fixed	Introduce basic foundation for automation in adblockplusui	User-Interface	agiammarchi
#6309	closed	fixed	Start using SASS in adblockplusui	User-Interface	agiammarchi
#6310	closed	fixed	Start using JavaScript modularization tool in adblockplusui	User-Interface
#6311	closed	worksforme	Make a use of templating engine and/or Web Components and/or VirtualDOM in adblockplusui	Unknown
#6426	closed	rejected	Start using CSS modularization tool in adblockplusui	User-Interface	agiammarchi

Note

This is a master ticket for fixing the issue.

[saroyanm]

Thomas I think it's not very high priority right now, but I think it make sense to start discussing it when you/me have time aside from prio projects.

I think it make sense to come up with the existing modular approaches that are being used by different modules, in order to find some unified approaches.

I do know that we are using GULP and SASS for the Website projects, but I don't know which exact tools are being used in the Flattr ?

[saroyanm]

I think the description of the ticket is high level enough to make it ready and add sub tickets when needed.

[greiner]

This is a duplicate of #4267 but since this one concerns the entire adblockplusui repository I'll close the other one instead.

I think it make sense to come up with the existing modular approaches that are being used by different modules, in order to find some unified approaches.

Platform is using Webpack so no matter what we decide on, we at least need to ensure compatibility.

I do know that we are using GULP and SASS for the Website projects, but I don't know which exact tools are being used in the Flattr ?

We use Gulp as our build system, Browserify for bundling Node modules, Mocha for testing and various linters - no CSS preprocessors though.

[saroyanm]

I think it will take time to determine all components that needs to be separated, we can separate components step by step, whenever we notice that we can move component into separate module after this is finished, or as soon someone will invest time and determine all components, either way I think we can mark this ticket ready and at least have basis to do so.

[agiammarchi]

Replying to saroyanm:

I think it will take time to determine all components that needs to be separated, we can separate components step by step, whenever we notice that we can move component into separate module after this is finished, or as soon someone will invest time and determine all components, either way I think we can mark this ticket ready and at least have basis to do so.

I feel like my tooltip ticket/story is somehow related.

I either need some specific tooltip only JS and/or CSS.

Maybe it makes sense to propose a couple of solutions to bring modules in ?

[agiammarchi]

tooltip component

[agiammarchi]

Since I've mentioned components, and I'm working on one, I'd like you all to have a look at the simple structure proposed and described in the README.md.

It's an idea based on gradual migration from what we have now in ABP UI. Please let me know if it makes sense or even if this is the right place to discuss that, thanks.

[greiner]

Interesting concept. So, if I understand you correctly, instead of having a file structure such as

css
  common.css
  a1.css
  a2.css
  b.css
images
  x.svg
  y.svg
  common.svg
js
  common.js
  a.js
  b1.js
  b2.js
a.html
b.html

we'd have something like this?

common
  css
    common.css
  images
    common.svg
  js
    common.js
a
  css
    a2.css
  images
    x.svg
  index.css
  index.html
  index.js
b
  images
    y.svg
  js
    b2.js
  index.css
  index.html
  index.js

If so, that'd be fine with me as long as it can accomodate sharing of code and other assets (as indicated by "common" in the example) between components.

[agiammarchi]

it's up to us, really, but I prefer to have related files in one place instead of switching folders all the time.

It's simple to work within the IDE this way too. However, the main concept I'd like to have is the test-ability of each component in isolation with the most basic structure to validate its functionality. This will simplify a lot automations and testing of our UI. We can launch various seleniums to various address in parallel and be sure in few seconds all is good.

About that, I find their setup inspiring (testing wise): ​https://custom-elements-everywhere.com/

Maybe there's something we can learn from them, they have isolated various frameworks all sharing the same JS/UI/components.

[agiammarchi]

on a second thought, I think Thomas structure is cleaner. Working on components these days, it's not that I switch fodlers all the time, I rather need to have required modules/utils/js files around.

Sorry for jumping it too early on this. Anyway, I think we should re-prioritise either this ticket or those JS modules related becuase now I have various UI components that cannot land in current UI due current monolith approach.

[greiner]

@saroyanm All the tickets referenced in this meta ticket have been closed so can this ticket now be closed as well?

[saroyanm]

Absolutely.