Clarity: [CORE/NG] Modularize Clarity

[youdz]

Currently, we export a single module that contains every single one of our components. It makes it impossible to treeshake Clarity, or even to write unit tests without compiling the whole library.
On top of that, the number of components we have is starting to be too much for a flat structure, so we need to reorganize the project.

Here is the proposed folder structure for clarity-angular/ (which I just realized is poorly named, since it also contains the source for clarity-ui).

 ├─ animations (needs a rewrite from scratch)
 ├─ close
 ├─ conditional
 │   ├─ if-active
 │   ├─ if-expanded
 │   ├─ if-open
 │   └─ ...
 ├─ loading
 └─ scrolling-service (?)
button
 ├─ button-basic (?)
 ├─ button-group
 └─ button-spinner
code
 ├─ example (?)
 └─ syntax-highlight
colors (all CSS)
data
 ├─ datagrid
 │   └─ (preserve structure for now)
 ├─ stack-view
 ├─ table
 └─ tree-view
drag-drop
emphasis
 ├─ alert
 ├─ badge
 └─ label
forms
 ├─ checkbox
 ├─ date
 ├─ input
 ├─ radio
 ├─ select
 ├─ time
 ├─ toggle
 └─ ...
icons
layout
 ├─ card
 ├─ grid
 ├─ login
 ├─ main-container
 ├─ nav
 └─ tabs
modal
 └─ dialog (?)
popover
 ├─ common (private, do not re-export from PopoverModule) 
 ├─ dropdown
 ├─ signpost
 └─ tooltip
progress
 ├─ progress-bar
 └─ spinner
typography
 └─ list
wizard

(?) means the component is either not written yet, not decided on, or possibly not needed anymore.

Each folder declares an Angular module, so that each component can be imported individually by importing its corresponding module. Each folder that contains sub-folders declares a module that exports the corresponding sub-modules.
Of course, modules can depend on one another, but we have to make sure our own modules only import what's strictly necessary. For instance, TreeViewModule will not import all of FormsModule, but only CheckboxModule.

Note that there are a few constraints that we need to respect at all times:

• If a folder contains sub-folders, it cannot contain an Angular component or directive at its root. That would make it impossible to import said component in isolation.
• We need to avoid dependency cycles.
• If we anticipate on a new component, we need to make sure it can be added to this tree without breaking changes.

SCSS files will follow their respective components, but note that contrary to Angular components, they can be at the root of a folder that contains sub-folders.

This should be done without breaking changes, which means our main index.ts and ClarityModule need to export the same classes and components as they did before the reorganization.

[chunghha]

Thumbs up! For users to import certain components individually will be so nice, great!

[imcotton]

Any thoughts on making scoped package (e.g. @clarity/angular) just like Angular is doing right now?

[youdz]

@imcotton: We considered it initially, but if I remember correctly there were some internal constraints at VMware that prevented us from doing so.

These constraints might not exist anymore, so I'll raise this with the team and see if it's now something we want to do.

[github-actions[bot]]

Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.