Migrate from v6 to v7 #560
filiptammergard
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Breaking changes when migrating from v6 to v7:
Color primitives
The color primitives structure is revamped to increase flexibility and scalability. The color themes are built using color primitives. While a theme color property changes depending on active color theme, a color primitive is always the same. The intention is that the color primitives only should be used by library consumers directly as an escape hatch in rare cases.
The hope is that the evolved color primitives structure with the related theme updates (see next section) will make the theme cover a larger set of color needs and thus reduce the need of reaching for color primitives, while also providing a scalable foundation for future color primitive additions.
Detailed color primitive updates
In v6, there were three color variants for all base colors, using
light
,default
anddark
as property names. See thegreen
base color object as an example:There has been a need for a fourth color variant, but it was not obvious what property name to give it. Instead of adding something like
lighter
ormedium
, we decided to change the color primitives structure in v7 to allow for adding more colors in the future without breaking changes or awkward property names. The v7 structure use numbers as property names instead, like this for thegreen
base color object:With this change, adding a new color variant is as easy as adding a new property with a logical property name number depending of the brightness of the color (
10
if it's lighter than the20
variant as an example).In v6, there were a
greyscale
base color object:In v7, we decided to change the pattern to align with the other colors:
Instead of
white
andblack
being a part of thegreyscale
object as in v6, they are placed in the root of the color object in v7:Here are some examples of changes in how to access the primitives in v7 compared to v6.
Theme
The deprecated
customTheme
prop is removed from<EinrideProvider>
. It was used in the early stage of Einride UI, mainly for the website, but is not needed anymore.The type of the
theme
prop on<EinrideProvider>
is changed fromany
toDeepPartial<Theme>
to make it easier to know how the theme is supposed to be overridden.The default value of the
colorMode
prop on<EinrideProvider>
is changed fromlight
tosystem
. If you want to continue forcing light color mode, you need to set it explicitly.The deprecated theme properties
theme.colors.background.reverse
andtheme.colors.content.reverse
are removed. UseprimaryInverted
instead ofreverse
. This naming change was done to allow better for usingsecondaryInverted
as an addition toreverse
/primaryInverted
.Theme deprecated theme property
theme.grid
is removed. It's not used anywhere and if we need grid helpers in the theme in the future we'll add them then.secondary
andtertiary
theme background properties have been updated to use opacity, to allow better for using components inside of containers with various background colors. If there is a need of opting out of the added opacity,secondaryElevated
andtertiaryElevated
can be used, respectively.Rationale behind using opacity
If you wanted to use an input inside a card with
background="secondary"
in v6, there was no contrast between them:For that reason, a
secondaryOpacity
theme background property was introduced, which gave contrast between the two:Using opacity provides flexibility in the way it allows for putting a component on an arbitrary background. Here's the same input component on a card with a random blue background:
It adds contrast while still letting a part of the background bleed through. Compare that to using the default background without opacity in v6:
Looks awkward. Another benefit related to using opacity is that it works in an arbitrary amount of levels. Here's an input in a card in a card as an example:
They all have contrast automatically, while still using the same theme background property. This technique is used by for example Apple to provide flexibility out of the box. Providing the same flexibility without opacity would require adding many new theme color properties, which would in turn make it more difficult to know when to use what theme property.
theme.colors.background.secondaryOpacity
andtheme.colors.background.tertiaryOpacity
are removed, since opacity is addedtheme.colors.background.secondary
andtheme.colors.background.tertiary
instead.positive
,warning
andnegative
theme background colors are revamped with increased vividness and without opacity. Unlikesecondary
andtertiary
theme background colors, these variants have proven to be better off not using opacity. Since these colors reflect a status (success, error or warning for example), they should not be influenced by container background color, as that could make the status information less clear. Positive should be positive independent on the background of the container.Components
<Label>
is updated to take advantage over the new color primitives. In v6, these were the available<Label>
variants:In v7, these are available:
This is also an example on how the new color primitives increase background color vividness, while using
primary
/primaryInverted
and text color property.The deprecated
columns
prop on<PrimaryButton>
,<SecondaryButton>
and<TertiaryButton>
is removed. It was used in some places in an early stage of Einride UI, but it's not supposed to be used anymore.The deprecated
<Popover>
component is removed. Use<Alert>
or<Sheets>
instead.<Alert>
should be used for small mandatory confirmation actions and<Sheets>
should be used as a regular dialog with the possibility to show more content.The deprecated
<Segments>
component is removed. Use<Tabs>
instead.All deprecated
*Styles
props are removed. Use the corresponding*Props
instead. The reason behind this change is added flexibility, since*Props
accepts a larger set of of properties (onClick
,role
andtabIndex
to give a few examples) compared to*Styles
.<PrimaryCard>
and<SecondaryCard>
components are removed. Use<Card>
instead.The reason behind this change is that there were a lot of confusion around when to use
<PrimaryCard>
and when to you<SecondaryCard>
, as well as what the difference between them except the background color was. For these reasons, the component was simplified in the design system, and the<Card>
component is reflecting those updates.<Checkbox>
and<Radio>
are renamed fromonChange
toonCheckedChange
and takes a boolean instead of an event. The reason is to simplify API and align with<Switch>
.Beta Was this translation helpful? Give feedback.
All reactions