Component library for UI elements and accompanying style guide

[hacdias]

April 2020 update

Let's use this issue as a placeholder for future work on component-izing UI elements (including documenting them, style-guide-wise) in a manner that can easily be reused by all our helper apps as well as anyone else who'd like to build on the core IPFS look and feel.

Note: this should probably end up with its living home in the IPFS UI Style Guide. See issue ipfs-inactive/ipfs-ui-style-guide#2 (closed in favor of this meta-issue).

Original issue text follows:

Over the last week, I opened some issues, PRs and a repository. All about the same thing: reusable components. And I'm opening this issue to get a central point to discuss everything about this and define priorities and goals.

So, first of all, the references:

• ipfs-desktop
  • Fixes Bunch ipfs-desktop#596
• ipfs-webui
  • Restructuring WebUI ipfs-webui#616
  • Reusable Components + New UI ipfs-webui#618
• ipfs-react-components: https://github.com/ipfs-shipyard/ipfs-react-components

@akrych published the first Web GUI Kit on #7 yesterday and it is amazing and there are some things I want to get clear before moving more than I've moved.

During the last week, I fixed some stuff on Desktop, but it was on the PR related to the components so this won't get merged soon, but I am proposing the following.

About IPFS Desktop

This will be the priority for now. @akrych will start drawing some wireframes for it and we can start implementing the new UI on it right after. I started using the ipfs-react-components library on the PR I created (ipfs/ipfs-desktop#596) but I'm thinking about moving the components to a directory on IPFS-Desktop or use a Git Submodule.

Why? There is an issue with Electron Forge and it is making it very hard to deploy and develop faster since I can't link the module.

Steps I suggest to do:

1. Move the ipfs-react-components components again to IPFS-Desktop repository.
2. Fix the issues I've got listed on Fixes Bunch ipfs-desktop#596.
3. Implement the new UI scheme and during this part of the development, always make the components the more abstract as possible so they can be easily moved to a shared library.
4. Make this awesome!

About IPFS Companion

Since I'm not really into IPFS Companion, I'd like to ask you what do to next here 😄 /cc @lidel

About IPFS WebUI

After having IPFS Desktop with a nice UI and UX everyone agrees with (as you said @olizilla), we can move to IPFS WebUI. I was taking a look at the OKRs we've got defined for this quarter and saw this:

ipfs-dashboard is built as a reusable replacement for ipfs-web-ui

It was classified with priority 4. My suggestion is to forget the PR I started (ipfs/ipfs-webui#618) and start working on ipfs-dashboard using the new elements and the new UI. And, when it gets finished, we can replace IPFS WebUI by IPFS Dashboard.

About the Reusable Components

So, as you all probably know, I created a repository called ipfs-react-components and I was very happy because it was all working. But now it seems it was slowing me down a bit. My suggestions here are to:

1. Wait until we have the new GUI Kit implemented on ipfs-desktop.
2. Then implement this elements and move some of the other reusable elements created on ipfs-desktop to that repo.
3. Then, use it during the development of IPFS Dashboard.

In the meanwhile, all the components we make should be "stupid" components, I mean, they don't need Electron's or the browser APIs to work. They receive information and they just work.

---

What do you all think? Let's make this clear and move forward fast. 😄 Sorry for not having this clear yet.

[lidel]

@hacdias I expect it will be easier if you focus on Desktop for now and make it awesome.

Just like you suggested, having components in the same repo (or submodule -- pick which one makes more sense to you) will enable you to iterate faster. As your work progresses you will see opportunities to extract things that implement Web UI Kit into reusable styles and components.

I would not migrate other apps to them until you feel it is safe to switch Desktop itself to styles/components from external repo. Ignore Companion for now, it would be only a distraction, given it uses tachyons and choo for UI right now. We will apply UX changes to it later, when UI kit is stable.

ps. we need to reword the KR about WebUI, because name change was vetoed: ipfs/ipfs-webui#612 (comment)

[hacdias]

@lidel for now, I'll keep them on the same repository for now and focus only on Desktop. I'll now focus on Desktop and start moving things over to another repo when the UI kit is more stable and when I feel I can use them on Desktop 😄

[olizilla]

I'm interested in how we'd like to implement the shared components and the UI style guide.

After spending lot's of energy trying to wrangle ui systems that worked at the bootstrap kind of scale of components, I'm now more interested in things that focus on much smaller building blocks, like common type, colour and spacing, that are be really nice to play with, and trivial to compose, like tachyons.

As a (p)react friendly extension of those ideas, I'd like to propose https://github.com/jxnblk/styled-system as part of our plan. We can export the core values of the style guide as a json object as per https://github.com/jxnblk/styled-system#configuration and iterate on products independently without to much co-ordination, and still retain a shared look. If we can agree on those fundamental building blocks, then once we've got a bunch of UIs we can start to extract and share composite components where useful.

[jessicaschilling]

Linking to (closed) #7 for the sake of reference -- there are lots of mockups in here that we don't want to lose sight of for future work.

[jessicaschilling]

Linking to (closed) #76 for reference on prior work undertaken for a shared React component library.