Discovery: Material UI library

[kmyram]

Material Design is implemented in a React framework not supported by Google (because Facebook). Official implementation is in vanilla js. Unofficial implementation in React is Material UI. Widely used. Not supported. Implements material design well but we are not using material design globally.

Criterias: Do we implement the non-supported React-versionand risk putting a stamp of approval one it? How to implement the VanillaJS version but less used? Used by Sitekit…

What to investigate (discover):

• How easy is it to implement the...
  • Custom
  • Official?
  • Non-supported React framework
  • Put in a pro et con table
  • Has to be done by the same developer
• "Balanced scorecard"
  • Support on PR's
  • Frequent updates
  • Parity with Material Design
  • Ease of implementation
  • Support on product, alert/notification

[spacedmonkey]

The three options to do discovery are the following.

1. Use the material-components-web library by Google.
   • Investigation how the site kit team has integrated this library into React.
2. Use the material-components-web-components library by Google. This library is extremely new and may not be ready for a production project.
3. Use the material-ui library not by google.

[swissspidy]

@pbakaus What's your opinion on the officiality of those libraries? Should it be a factor?

[pbakaus]

I don't have an opinion, but we should absolutely ask our Material friends. I'll kick off an internal thread.

[swissspidy]

Sounds good. Otherwise my 2 cents in yesterday's meeting were basically that we should just start using Material UI with a small abstraction layer around it. We lose valuable time discussing this, and I think from our discussions it was quite clear that Material UI had most benefits. With a small abstraction layer we can always swap it out for one of the others after beta if needed.

[spacedmonkey]

After review of the different options here are my findings.

1. Use the material-components-web library by Google. It would be possible to integrate this into react / stories editor. The site kit team have already done something similar. However, the effort to do so, would not be worth the benefit and would produce worse results. Hacking this library into react, feel wrong.
2. Use the material-components-web-components library by Google. Similar issue as noted above, the library is not designed for react, so would take a long time to integrate in react. Also many of the components are not completed.
3. Use the material-ui library not by google. This is a solid well documented library with a large community behind it. The documentation on the site is extremely good. It even intergrated with styled-components, which would allow us to override any styling we do not like. I have a PoC PR for integrating material UI.

I had some with components becauses of forms.css. This css resets lots of the input / form fields, which is already an issue. CC @swissspidy here, on his thoughts on removing it.

[swissspidy]

The list of components that @samitron7 shared:

• Dialog box (We'll need to create a hybrid notification/messaging system as the dialog box and snack bar will not serve our needs for the editor)
• Snack bar
• Textfield (Do not recommend we use their textfield. It's heavy and not right for the design panel)
• Button
• Accordion menu (We'll need to modify these)
• Image list (This is the one nice feature they have)
• Menus
• Progress indicator (I don't like the animation they have)
• Tabs
• Tooltip (Not crazy about their styling)
• Sliders (May need to modify)

[swissspidy]

Short summary so far after our discussion before:

• Material UI can be quite inconsistent
• It might be easier to roll our own simple components, especially for the cases where they diff drastically from MD
• Material UI can be useful for bigger components like Dialog and Snack bar. It can be tweaked easily to suit our needs

• 271 is quite far advanced, and covers many of these simple components already. There aren't many open to-dos.

[swissspidy]

@wassgha How much time do you think is needed to finish the work on the form elements in #271? Do Would you need help on that or someone to take it over? Panel refactoring can be done separately. If we have form elements, that could unblock lots of other things.

[wassgha]

Shouldn't be too hard, but if anyone wants to work on it we can merge what we currently have and work on the remaining components in a separate PR

[barklund]

@wassgha How much time do you think is needed to finish the work on the form elements in #271? Do Would you need help on that or someone to take it over? Panel refactoring can be done separately. If we have form elements, that could unblock lots of other things.

We have @ndev1991 and @obetomuniz assigned to #255 now and will take over #271 and work from there.

[spacedmonkey]

Moving to done as library is going to add much overhead than benefit.