Refactor `ui-components`

[amaury1093]

trafficstars

@goldsteinsveta and I discussed a little bit about ui-components, we agree it needs a refactor.

So the idea is: ui-components should work towards being the de-facto design system of Parity.

Here's a quick summary.

Replace constants with tachyon scales.

In our app, or in ui-components, we should only in rare-cases hardcode numerical values like 2px or 3rem. Prefer in general tachyon scales "mr2" or "w100".

Better folder structure

Ideally, we could avoid having one folder with 100 component files. I once proposed to categorize components like SUI does. But we could see how other big design systems categorize them, and/or find something that makes more sense to us.

globalStyle

Only for modifying body, html, #root and app-wide styles (e.g. font).

Shared.styles

Shared.styles.ts has a lot of components inside it.

We could split out these components into like Button.tsx, Text.tsx, Stacked.tsx, and each of these files would hold ~5-10 variants of that component.

Readability

Still tbd: should we keep components like <Margin top />? It's good for readability, but it unnecessarily adds a <div> in the DOM.

<div>
  <MarginTop />
  <Button />
</div>

// VS

<div>
  <Button className="mt2" />
</div>

Happy to discuss other ideas about ui-components here!

cc @yjkimjunior

[pmespresso]

First 4 points sound good to me!

w.r.t Readability, I like <Button className="mt12" /> more, but would put this pretty low on priorities.

In Nomi and Polkassembly there are components, typography, colors that are used that don't exist in ui-components. I think they look quite nice, however, they're not part of the "official" designs.

I'd like the ask, what sort of system should we have for getting such components into our official ui-components library, and what guidelines should we set for ourselves and future maintainers for going "off-road"? Would such a document be helpful to others, or is it just me? I don't want to step on any toes and I also don't want discussions around design to become siloed amongst one or two people because others feel like they're overstepping their "domain." But maybe that's just me.

cc @Tbaut @erler

[goldsteinsveta]

I'd go about it like:

0. Remove unused components #914
1. Replace hardcoded values with tachyons scales #914
2. Replace constants with tachyon classes, their combos or with props that define tachyon classes where needed
3. Sort out and split Shared.styles
4. Folder structure, readability decisions (on the concrete example of light-apps)
5. Brush up globalStyle to serve the new structure
6. Documentation stuff: Storybook, Figma styles to reflect tachyons scales, colors, SUI details etc

With this done we will have a universal way to describe and maintain UI for designers and developers. This is in no way what a standard UI should look like, but rather a draft of what it should consist of to move as seamlessly as possible from des to dev stages and to be shared around without much hustle. I think it worth doing even if it serves only light-apps though.

And this is where refactoring ends and discussions begin.

7. ~~decisions~~ discussions on whether, and if so then how, components from other apps could be integrated into this system, what to count as "official" and "off-road" design, what to do about cross-chain apps and differentiation of Parity / Polkadot / Substrate.

8. In a galaxy far, far away – utilise Figma API to push designs straight into the globalStyle themes, Storybook front-end testing etc

[erler]

In Nomi and Polkassembly there are components, typography, colors that are used that don't exist in ui-components. I think they look quite nice, however, they're not part of the "official" designs.

I'd like the ask, what sort of system should we have for getting such components into our official ui-components library, and what guidelines should we set for ourselves and future maintainers for going "off-road"? Would such a document be helpful to others, or is it just me? I don't want to step on any toes and I also don't want discussions around design to become siloed amongst one or two people because others feel like they're overstepping their "domain." But maybe that's just me.

cc @Tbaut @erler

As Kaye and Zsofia are currently running a bigger project looking into how the different brands (Parity, Polkadot, Substrate etc.) relate to each other and where the different UIs sit in that space, it probably doesn't make sense to have a super strict (visual) guideline as of now. However, it could be useful to establish some once the relationship between the different brands and products, and their respective visual identities, have been clarified a bit more.

What I was thinking would be nice (but obviously extra work) at some point is to have a more outwards facing web3 component library / collection for the community to use. I'd imagine that kind of collection to be more concerned with ways of interacting and displaying web3-specific things rather than branded styles. Rather than organising such a library in buttons, tags, inputs etc. it could be organised around recurring blockchain app themes, e.g.

• Blocks and Time: e.g. BlockCountdown, EraProgressBar, BlockTimestamp kind of components
• Identity and Addresses: ways of displaying, selecting, copying addresses and identities etc.
• Locked funds: UI that is concerned with things like bonding funds for nominating, vote locking, smart contract rent endowments etc.

This would be less of an internal library for the sake of productivity, but could be a good way to share and engage with the community.