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 https://github.com/ipfs-shipyard/ipfs-ui-style-guide/issues/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
  • https://github.com/ipfs-shipyard/ipfs-desktop/pull/596
• ipfs-webui
  • https://github.com/ipfs-shipyard/ipfs-webui/issues/616
  • https://github.com/ipfs-shipyard/ipfs-webui/pull/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 (https://github.com/ipfs-shipyard/ipfs-desktop/pull/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 https://github.com/ipfs-shipyard/ipfs-desktop/pull/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 (https://github.com/ipfs-shipyard/ipfs-webui/pull/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.