Research minimal UI component libraries

[alkiko]

We will build a new UI component library that will initially be used to implement the tradedesk.

The new UI library should be general enough to also be used on:

• cloud.cinemataztic.com
• dch-p
• future electron, react and perhaps react-native projects

Current CineAd Tradesk prototype state (26/11/2021) can be viewed here.

As the deadline for the CineAd tradedesk MVP is february 22, we need consider using an existing minimal UI library to make it on time. Considerations when choosing the base UI library:

• Minimal build toolchain
• Theme-able: tradedesk may be a whitelabel solution for several customers
• Not too opinionated (e.g. not framework/library specific)
• Lock-in: should be easy to remove the base UI library dependency
• Learning curve: easy to learn
• Good API - we will likely be inspired by this API to preserve compatibility if we decide to ditch the base UI library down the road
• Flexibility/customisability
• Few dependencies

[MikkelWestermann]

I started using the Headless UI library on the new DCH-P and I think that is quite nice to work with. It's build by the tailwind guys, so it works very well with tailwindcss if we want to use that. It's lightweight and the styling is minimal. I think we could use it as a building block for our own UI component library in the long run, but it would provide basic components for now. We could build the components as we need them and have a folder with "atomic" components that we can then just move to a separate repo when we're ready to create our own library. This would make the transition a lot easier.

[alkiko]

Latest prototype: https://www.figma.com/file/njCnUrOH0qrvD1PW1Jc34H/CineAd?node-id=291%3A15586

First step will be to build a basic UI library that can be used to build the UI in the prototype.

Check it out 🎉

[MikkelWestermann]

Here is the example of the atomic components in the DCH-P: https://github.com/cinemataztic/DCH-P/tree/master/src/renderer/apps/setup/components/atomic

My idea is that we have this "atomic" directory (or a better name if anyone has an idea), where we build the very simplest components as we need them in the trade desk UI - based on Headless UI if they have it otherwise build it ourselves or find a different package. When we have enough (and the spare time) we can then move the atomic directory out of the repository and into its own with storybooks, etc.

[pixochi]

I'm looking into Chakra UI:

• It has all foundational components you can think of, which would allow us to build the Tradedesk UI quicker.
• The components are themeable and the library even offers dark mode out of the box.
• Not very relevant to us, but they have a convenient system for media queries.
• The documentation is great.
• It's very popular: https://github.com/chakra-ui/chakra-ui.

You can see the full comparison to Tailwind CSS here. IMO the main advantages of Chakra UI over Headless UI are:

• styles of components in Chakra UI are overridden via props (the React way) rather than overriding CSS classes
• Chakra UI has a much wider selection of components

Since our UI library will be used across multiple projects, we should set up a flow and preemptive measures for creating and editing components in this repo, e.g.:

• set up Prettier
• set up ESLint
• each PR should require at least 1 approval, I'd suggest 2 as the UI library grows
• write at least one simple Enzyme test for each component
• follow best naming conventions, documentation and other standards we agree on, etc.

This is a great example of how to build a custom component library: https://www.youtube.com/watch?v=hf6Z8OZanec

[MikkelWestermann]

I've looked at Chakra UI in the past as well and I think it looks very interesting! I agree that using Chakra would allow us to build the Tradedesk UI quicker, because of the wider selection of components. But isn't a wide selection of components what we want to get rid of? Currently we're using Semantic UI, which is your "everything and the kitchen sink" kind of library and I think Chakra is quite similar in that regard.

[pixochi]

We wouldn't use all Chakra's components but I think it's good to have the option to reach into Chakra UI as the deadline is approaching. If we encapsulate each component like you did in DCH-P, we can eventually replace all Chakra components with our own implementation when we have time.

[sandhana14]

UI components

I developed the following components using Headless UI/Tailwind CSS and Chakra UI/Styled components:

1. Button

2. Input field of type datetime-local

3. Radio button

4. Checkbox

5. Range slider

6. Listbox(select)

Headless UI and Tailwind CSS

From the above components, only two components such as Listbox(select) and Radio button are available in the Headless-UI. In general, all components are completely unstyled in Headless UI, but it provides the functionality that we need. Remaining components are not available in the Headless-UI, so I designed these components from scratch.But it didn’t take much time to design from scratch using Tailwind CSS. I felt that my experience in working with Tailwind CSS has been great so far..

If we choose to go with Headless-UI/Tailwind CSS, we have to build most of the components from the scratch which can be time consuming. But having said that, I must add that it is nice to work with Tailwind CSS as there are lot of resources available to customize the components to our requirements.

You can find the implementation of all the above-mentioned components using Headless UI/Tailwind CSS in the pull request of Cine-ui repo. Command to run the code is npm run storybook. In the side bar of storybook, under form component, you can find all the components together in one page.

Chakra UI and Styled components

All the above-mentioned components are available in Chakra UI out of the box. Chakra UI itself has a style props option to style the components by simply passing props to it. But if we want to customize the components in the way we want, It is not possible only by using style props. We also have to use styled components to achieve the desired design.

I felt that it was little hard to customize the components in the way we want it. However, the experience with styled components was relatively good.Though all the needed components were available in chakra UI it took nearly the same time to customize as that of headless UI / Tailwind CSS to achieve our requirement.

My general opinion

While working with both, I faced certain difficulties. With regards to Headless UI /Tailwind CSS and building components from scratch, I was able to find solutions to many of the problems faced during my work. But I couldn’t find much resources for the issues that I faced with chakra UI even though the documentation of the Chakra UI is good.

Both have similarly good theme customization options(needs further investigation)

In our wireframe, one of the main component that we have to develop is a sidebar / side bar with sub menu.Such a feature is not available in Headless UI, but there are lot of possibilities to design them using react/third party libraries(which needs to be investigated further). Sidebar component is available in Chakra UI as a template built by others but it is not available as standard. If we use Chakra UI ,we have to do a lot of customization in order to achieve our goal.

You can find the above developed components using Chakra UI/Styled components in the pull request of Cine-ui-chakra repo which is a private repo in my Github account. Command to run the code is “npm start”. I shall share this repo for your reference.

I have given my opinion based on my short stint with these libraries/CSS frameworks.

Looking forward to your feedback on the same.

[pixochi]

UI components

@sandhana14 Thanks for the exhaustive review :+1: I'll have a look at the code today or next time I'm working.

[pixochi]

@sandhana14 Could you tell us what branches include your latest changes and we should test? And where could we find the repo with Chakra UI? :)

[sandhana14]

Sure @pixochi... cine-ui repo - set-up branch , cine-ui-chakra repo - form-components branch.. I invited you as a collaborator in order to access the cine-ui-chakra repo on that day we discussed.

[MikkelWestermann]

I think they both look like good options! We would need to break the components down further if it were to be used as a component library (for instance, the input component in cine-ui should just be one input), but it creates a fine overview of what we're going to do with the UI.

It seems like we would be building a "final version" (in the sense that we wouldn't be required to replace a third-party-library) of the component library with the Tailwind/Headless UI option along with building the tradedesk. On the other hand, if we chose the Chakra solution, then we would be wrapping the Chakra components and then replacing it with our own implementation later. Is that your experience as well, @sandhana14? I think both are valid approaches with their own advantages and disadvantages - fx. with the Chakra option we need to make sure we abstract the logic of the components adequately, but it provides more components out of the box.

They both seem quite similar in terms of how easy they are to work with, but I can't really testify to that as I haven't worked much with it. It appears that you find the Tailwind/Headless UI option slightly easier, is that correct @sandhana14? Or is it much the same? Also did you encounter anything that would indicate that one solution would be more scalable than the other?

I don't really have a strong opinion in either direction at this point - I think both paths could lead to a good solution.

[sandhana14]

I agree with you that both of them are really nice to work with. But I personally prefer to work with Headless-UI/Tailwind CSS for available components and if components are not available in Headless-UI then building such components from scratch could be done in lot of other ways. In addition, it is also easier to customize and implement these components when compared to that of Chakra UI. With regards to this, we have plenty of resources out there in the internet to refer.

Since we are going to implement our own UI component library, as you mentioned, it is not necessary to replace the third-party library with our own implementation later,If we use Headless UI/Tailwind CSS . So I second your opinion in this regard.

What do you mean with regards to scalability in this context? Should the UI be scalable to accommodate more elements in the future?

[MikkelWestermann]

With regards to scalability I was referring to whether we would encounter problems as we add more components down-the-line. This involves anything that could become problematic later, for instance it could be bloated global configurations, build/bundle size, build tooling around the packages, whether one solution is strongly opinionated with regards to layout etc.

[pixochi]

If building the components with Tailwind/Headless takes a similar amount of time as customizing Chakra components, then I think we should go forward with Tailwind/Headless. It looks like we all agree on that now.

And we can use Chakra in a different way - we can use its components' interfaces as inspiration for our components. E.g. have a look at the Button component, just for illustration: https://chakra-ui.com/docs/form/button - instead of always passing both height and width props to Button, you can pass just size. This kind of interfaces, which limits variations to reasonable options, can help us keep the UI more consistent.

@sandhana14 If nothing critical relating to the UI libraries comes up, you can ping us for review of your PR https://github.com/cinemataztic/cine-ui/pull/2 if it's ready.

[sandhana14]

I have to investigate a bit more about scalability and then I’ll let you know @MikkelWestermann

[sandhana14]

@pixochi As per your suggestion, I am planning to refer Chakra component’s interfaces for the implementation of our cine UI components. I’ll make the necessary changes and then will let you know about the review. Thanks