#6117 closed change (fixed)

Create bases for Adblock Plus UI Modularization

Reported by: saroyanm Assignee:
Priority: P3 Milestone:
Module: User-Interface Keywords:
Cc: greiner, ire, wspee, juliandoucette, agiammarchi Blocked By: #6303, #6309, #6310, #6311, #6426
Blocking: #6322 Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by 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:


Note

This is a master ticket for fixing the issue.

Attachments (1)

tooltip.zip (5.2 KB) - added by agiammarchi 21 months ago.
tooltip component

Download all attachments as: .zip

Change History (19)

comment:1 Changed 23 months ago by saroyanm

  • Cc wspee juliandoucette added

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 ?

comment:2 Changed 23 months ago by saroyanm

  • Priority changed from Unknown to P3
  • Ready set

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

comment:3 Changed 23 months ago by saroyanm

  • Summary changed from Modularize options page to Modularize Adblock Plus UI

comment:4 Changed 23 months ago by 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.

comment:5 Changed 21 months ago by saroyanm

  • Ready unset

comment:6 Changed 21 months ago by saroyanm

  • Blocked By 6303, 6309, 6310 added
  • Cc agiammarchi added

comment:7 Changed 21 months ago by saroyanm

  • Description modified (diff)

comment:8 follow-up: Changed 21 months ago by saroyanm

  • Ready set
  • Summary changed from Modularize Adblock Plus UI to Create bases for Adblock Plus UI Modularization

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.

comment:9 Changed 21 months ago by saroyanm

  • Blocked By 6311 added

comment:10 Changed 21 months ago by greiner

  • Blocking 6322 added

comment:11 in reply to: ↑ 8 Changed 21 months ago by 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 ?

Last edited 21 months ago by agiammarchi (previous) (diff)

Changed 21 months ago by agiammarchi

tooltip component

comment:12 Changed 21 months ago by 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.

comment:13 Changed 21 months ago by 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.

comment:14 Changed 21 months ago by 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.

comment:15 Changed 20 months ago by 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.

comment:16 Changed 20 months ago by agiammarchi

  • Blocked By 6426 added

comment:17 Changed 13 months ago by greiner

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

comment:18 Changed 13 months ago by saroyanm

  • Resolution set to fixed
  • Status changed from new to closed

Absolutely.

Note: See TracTickets for help on using tickets.