paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 47 Packages Projects Releases Wiki Activity

fix: use Material UI vs. MUI where relevant

Browse Source 
Signed-off-by: Olivier Tassinari <olivier.tassinari@gmail.com>
This commit is contained in:
Olivier Tassinari
2023-07-04 23:22:34 +02:00
parent b5344d21db
commit a51fb51617
57 changed files with 156 additions and 153 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/dls/component-design-guidelines.md
+6 -6
View File
@@ -7,7 +7,7 @@ description: Documentation on Design
Be it a new component contribution, or plugin specific components, you'll want
to follow these guidelines. We'll cover the three main subjects that define the
general look and feel of your components, all of which build on top of the
Material-UI theme features:
Material UI theme features:
- Layout
- Color palette
@@ -17,10 +17,10 @@ Material-UI theme features:
Layout refers to how you organize or stack content. Whenever possible, we want
to use Backstage's components (check the [Storybook][1] for a list and demo)
first, and otherwise fall back to Material-UI components (check the [MUI docs][2]).
first, and otherwise fall back to Material UI components (check the [Material UI docs][2]).
If none of these fit your layout needs, then you can build your own components.
However, using HTML+CSS directly is not recommended; it's better to use MUI
However, using HTML+CSS directly is not recommended; it's better to use Material UI
layout components to make your layout theme aware, meaning if someone changes
the theme, your layout would react to those changes without requiring updates
to your code.
@@ -43,13 +43,13 @@ specific styles for that component, that includes paddings, margins and colors.
However when making a component from scratch you'll need to reference the theme
as much as possible, make sure to use the theme's color palette. Most Backstage
components and all MUI components should use the theme's color palette by default,
components and all Material UI components should use the theme's color palette by default,
so unless you need explicit control on the color of a component (say when the
component was designed to use the primary color but you want to use the
secondary color instead), then the easiest way to access the color palette is
to [Override the Component Styles][11] as suggested by Backstage.
It's not a very common use case to override a theme color in a MUI component
It's not a very common use case to override a theme color in a Material UI component
but let's say you have a custom Sidebar component with a Paper component that
highlights its content with a different color for a side menu or something
(usually you use the elevation, but maybe the designer wanted a colorful app).
@@ -78,7 +78,7 @@ which tokens you can use as reference from the compiled theme.
## Typography
Most of the time the components from MUI will use the `<Typography />` component
Most of the time the components from Material UI will use the `<Typography />` component
which will use the theme's typography properties like font family, size, weight
and appropriate color from the palette for the context of that component. This applies for example to
buttons that use white font color for contained buttons, or the respective color
docs/dls/contributing-to-storybook.md
+4 -4
View File
@@ -14,8 +14,8 @@ You'll find our storybook at
[http://backstage.io/storybook](http://backstage.io/storybook).
As noted in the [design introduction](design.md), Backstage's design is based
off of [Material-UI](https://material-ui.com/). Much of the UI elements use
direct Material-UI, while we've also extended and written custom ones to provide
off of [Material UI](https://material-ui.com/). Much of the UI elements use
direct Material UI, while we've also extended and written custom ones to provide
specific functionality.
![Storybook Page](../assets/dls/storybook-page.png)
@@ -27,13 +27,13 @@ copied.
When custom Backstage components are created, they are placed in the
`@backstage/core-components` package and added to the Storybook.
There may be times where an existing Material-UI component (in
There may be times where an existing Material UI component (in
`@material-ui/core`) is sufficient and doesn't need to be wrapped or duplicated.
However, we may want to identify an _opinionated_ way to use that component
inside of Backstage. In these cases, stories showing how to use those existing
components will also be put into our storybook.
When a story example using Material-UI becomes more complex, requiring a
When a story example using Material UI becomes more complex, requiring a
specific set of colors, variants, parameters, etc., it may become a candidate to
be refactored to become a full Backstage core component.