Unify DS tokens integration

[evgenoid]

Button

Component changes:

• Removed default, success, error and warning color types
• Added destructive color type
• Added ghost variant type

Icon Button

Variants

Colors

Avatar

Checkbox

Dialog

Input

Textarea

List

###JSONTree

Menu

Notification

Radio

Range

Pager

Select

Tabs

Toggle

Tree

Calendar

Callout

DateInput

Kbd

Stepper

CommandPalette

Chip

[netlify[bot]]

✅ Deploy Preview for reablocks-storybook ready!

Name	Link
🔨 Latest commit	11f68dfdeae82578af45afdad8a5b4bd29df274c
🔍 Latest deploy log	https://app.netlify.com/projects/reablocks-storybook/deploys/69294724609ae400088c5c80
😎 Deploy Preview	https://deploy-preview-298--reablocks-storybook.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[steppy452]

@evgenoid initial thoughts - part of the reason I was splitting out the theme files completely was because migrating to the upgraded version without all of the tokens in place is going to be a problem. it feels like we need a v2 version of the theme that we can pull if we're starting with the new design system, but the original themes shouldn't change so much. let me know if that makes sense.

[evgenoid]

@evgenoid initial thoughts - part of the reason I was splitting out the theme files completely was because migrating to the upgraded version without all of the tokens in place is going to be a problem. it feels like we need a v2 version of the theme that we can pull if we're starting with the new design system, but the original themes shouldn't change so much. let me know if that makes sense.

Do you propose keep old and new theme in parallel? Or I don't get it?

[steppy452]

@evgenoid initial thoughts - part of the reason I was splitting out the theme files completely was because migrating to the upgraded version without all of the tokens in place is going to be a problem. it feels like we need a v2 version of the theme that we can pull if we're starting with the new design system, but the original themes shouldn't change so much. let me know if that makes sense.

Do you propose keep old and new theme in parallel? Or I don't get it?

I think yea, we'll need a new theme in parallel unless you can think of an easy migration path

[evgenoid]

I think yea, we'll need a new theme in parallel unless you can think of an easy migration path

I don't think we need it in parallel. If end-user wants to keep it looks previously but update the version, it can be rewrited with old tokens and theme configuration.

@SerhiiTsybulskyi what do you think about it?

[SerhiiTsybulskyi]

I think yea, we'll need a new theme in parallel unless you can think of an easy migration path

I don't think we need it in parallel. If end-user wants to keep it looks previously but update the version, it can be rewrited with old tokens and theme configuration.

@SerhiiTsybulskyi what do you think about it?

I agree with @evgenoid. Old and new theme structure (interface) have changes that will increase the complication.

[evgenoid]

@steppy452, before move forward we need to handle several core things because I see alot of repeateble comments:

1. Tokens level. On a 4th level we don't have any component unrelated tokens but in the same time DS using tokens of the 3rd level for some borders, backgrounds and text colors. Tokens of 3rd level still themed and has two different colors for light and dark modes. If you are still thinking that we need to use only 4th level then need to ask design team add it to this level and update the DS. But additional problem that some components in Reablocks don't have reflection in DS (Divider, Card, Stepper and so on) and we don't have 4rd level token for it for this reason.

2. Theme interface and tokens changing I believe we can provide in migration documentation old list of tokens and old theme object which users can add to project and continue use it if they don't want to spend time to adopt their project with new tokens.

3. Some component theme changing I think it's fine that some default properties (like variant, color) were changed. We will provide these changes in migration documentation and users should be able safely update it.

Before release we will test our updates on several internal projects and will see how it works.

My initial thoughts, when we started work on new DS was full aligning it with Reablock library. I even see on Austin's screenshots that some client asking about components library related to our DS. But finally we want just adopt Reablocks to new DS with minimal blood.

cc: @SerhiiTsybulskyi @amcdnl

Example of using tokens of 3rd level in components:

[steppy452]

@steppy452, before move forward we need to handle several core things because I see alot of repeateble comments:

1. Tokens level. On a 4th level we don't have any component unrelated tokens but in the same time DS using tokens of the 3rd level for some borders, backgrounds and text colors. Tokens of 3rd level still themed and has two different colors for light and dark modes. If you are still thinking that we need to use only 4th level then need to ask design team add it to this level and update the DS. But additional problem that some components in Reablocks don't have reflection in DS (Divider, Card, Stepper and so on) and we don't have 4rd level token for it for this reason.

Ahh I see what you mean. I was mistaken - I kept thinking 3rd level tokens were just a passthrough and not exported with the plugin. But it seems it is so this should be ok using 3rd level in some places 👍

2. Theme interface and tokens changing I believe we can provide in migration documentation old list of tokens and old theme object which users can add to project and continue use it if they don't want to spend time to adopt their project with new tokens.

3. Some component theme changing I think it's fine that some default properties (like variant, color) were changed. We will provide these changes in migration documentation and users should be able safely update it.

Before release we will test our updates on several internal projects and will see how it works.

sounds good - migration is one of the major pieces I worry about as we'll likely have to do this migration ourselves for a lot of our clients going forward. The more changes we make, the harder it will be for ourselves. but agree we can maybe do an alpha release and test on some internal projects first 👍