Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: reference component migration #1206

Merged
merged 33 commits into from
Nov 26, 2024

Conversation

Averethel
Copy link
Contributor

@Averethel Averethel commented Nov 15, 2024

References https://smg-au.atlassian.net/browse/FED-420

Motivation and context

The idea behind this PR is to have a reference when migrating our component library components.
I tried to showcase a few cases of components and refer to the specific examples further in the description.

Caveats

Unfortunately, GitHub doesn't detect file moves, even though I did my best to instruct Git to recognise them (i.e. move the files and then edit them in separate commits). To remedy that, I'll reference specific commits to showcase v2/v3 changes

Showcases

Re-exporting chakra component without theming

Adding more design tokes

Re-exporting chakra component while restricting the available props

Migrating a custom component build from chakra building blocks without custom theming

Migrating a component with defined styling

Migrating a custom component with multipart styling

Migrating a chakra component that is now a composite component

How to review this PR?

I suppose best way is to follow by migrations showcased and listed above. All of the changes are visible in highlighted commits

@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 15, 2024 12:12 Active
@Averethel Averethel force-pushed the chakra-v3/reference-migration branch from a227d43 to 653356b Compare November 15, 2024 15:14
@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 15, 2024 15:20 Active
@Averethel Averethel force-pushed the chakra-v3/reference-migration branch from 653356b to f713e8e Compare November 15, 2024 15:39
@Averethel Averethel force-pushed the chakra-v3/reference-migration branch from f713e8e to e099ce3 Compare November 15, 2024 15:45
import { Box, BoxProps } from '@chakra-ui/react';
export { BoxProps };
export default Box;
export { Box, type BoxProps } from '@chakra-ui/react';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simple re-export from chakra

@@ -1,2 +1,3 @@
export * from './icons';
export * from './themeProvider';
export * from './box';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to export the migrated component

@@ -1,32 +1,31 @@
import { Meta, StoryObj } from '@storybook/react';

import { space } from 'src/themes/shared/space';
import { sharedConfig } from 'src/themes/shared/index';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tokens in storybook can be accessed directly via the sharedConfig

@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 15, 2024 15:51 Active
import { Box, BoxProps } from '@chakra-ui/react';
export { BoxProps };
export default Box;
export { Box, type BoxProps } from '@chakra-ui/react';
Copy link
Contributor Author

@Averethel Averethel Nov 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Named export instead of default for better storybook code generation.

Before

<__WEBPACK_DEFAULT_EXPORT__>I am a box</__WEBPACK_DEFAULT_EXPORT__>

After

<Box>I am a box</Box>

This doesn't impact all of the components but we want to apply the same pattern for consistency.
You'd only see the __WEBPACK_DEFAULT_EXPORT__ on a branch deployment, locally it doesn't matter which type of export you use

args: {
width: 300,
ratio: 4 / 3,
children: 'box',
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storybook complains if we pass a react component as an argument. This is because all arguments need to be serialisable to reconstruct the story state via query params. We can leverage mapping in the argTypes to circumvent that.

More on dealing with complex values

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either create a new file for a token category that doesn't exist yet or add new tokens to the existing files.

To take a look at all design token categories in default chakra theme you can run:

$ npx chakra eject

This will create theme directory with default chakra theme. You can use it as a reference.

You will need to re-generate the type definitions after adding the tokens. Just run:

$ npm run typegen

Or, if you're changing a lot of tokens and want live updates you can run

$ npm run typegen:watch

@@ -20,6 +20,26 @@ const conversionToPixels = {
'Pixel values are only used as a reference for Figma designs. We use rem as units.',
};

export const AspectRatios: StoryType = {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're adding new token category - please add them to the storybook showcase so we can see the theme easily

@Averethel Averethel marked this pull request as ready for review November 19, 2024 16:21
@Averethel Averethel mentioned this pull request Nov 19, 2024
100 tasks
@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 20, 2024 08:17 Active
@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 20, 2024 10:06 Active
@@ -0,0 +1,22 @@
import { defineTokens } from '@chakra-ui/react';

export const aspectRatios = defineTokens.aspectRatios({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do they originate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are chakra defaults

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe align with UX if we wanna restrict them or they are good as is

| 'paddingBottom'
| 'paddingLeft'
| 'paddingRight'
| 'separator'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was the separator added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usage in the projects. We would do <Box as={Flex} separator={...} /> instead of using Flex directly

| 'marginBottom'
| 'marginTop'
| 'divider'
| 'margin'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does the requirement come from to extend all padding and margin props

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's been a change to how margins and paddings behave. In v2 you could pass them as object containing sides:

margin={{ top: 'sm', bottom: 'lg'}

This doesn't work anymore; an unqualified one applies the same margin (or padding) on each side. So to keep the existing functionality I whitelisted all sides explicitly

Comment on lines 41 to 67
export type TableCellProps = ChakraTableCellProps & { isNumeric?: boolean };
const Cell: FC<TableCellProps> = ({ isNumeric, children, ...props }) => (
<ChakraTable.Cell
{...props}
{...{ ...(isNumeric ? { 'data-is-numeric': true } : {}) }}
>
{children}
</ChakraTable.Cell>
);
Cell.displayName = 'Table.Cell';

export type TableColumnHeaderProps = ChakraTableColumnHeaderProps & {
isNumeric?: boolean;
};
const ColumnHeader: FC<TableCellProps> = ({
isNumeric,
children,
...props
}) => (
<ChakraTable.ColumnHeader
{...props}
{...{ ...(isNumeric ? { 'data-is-numeric': true } : {}) }}
>
{children}
</ChakraTable.ColumnHeader>
);
ColumnHeader.displayName = 'Table.ColumnHeader';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make it a breaking change and align over backwards compatibility, thinking there will not be 100s of cases where we need that

</Table.Footer>
</Table.Root>
</Table.ScrollArea>
),

args: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add some comments on the changed/extended interfaces and the reasoning behind (don't think it's bad but it can help follow what part are migration changes and which parts are improvements)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, of course. I followed the default table style and applied our customisations (similar to what we did in v2). The main change is that you now have more freedom when defining variants. In v2 you were limited to variant and size properties, in v3 you are free to define all the variations you need under the variant prop and have a fine-grained control over variants interacting with each other via compoundVariants. So I'm following the default configuration and embracing this approach. variant is a global look and feel and then we have different flags (like striped) that can be applied on top of that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if we should restrict the options here. I am not sure UX's intention would be to have so many variations

Copy link
Contributor

@lkappeler lkappeler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through your example and they are pretty clear. It feels a lot simpler/more straight-forward to work with than the current version.

I would be careful/explicit with improvement changes along with the migration, it makes it a lot harder to follow the context of wether it's required for some changes from v2 to v3 or something we can improve in our implementation

Copy link
Contributor

@lkappeler lkappeler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the chat we had this morning I do think we can merge this back to the stack root. Maybe check with UX on the restrictions but we can also do that down the road.

@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 26, 2024 13:49 Active
@Averethel Averethel force-pushed the chakra-v3/reference-migration branch from 1c285bb to 4d88158 Compare November 26, 2024 14:28
@automotiveengineeringbot automotiveengineeringbot deployed to branch-components-pkg-chakra-v3-reference-migration November 26, 2024 14:33 Active
@Averethel Averethel merged commit b007baa into chakra-v3/root Nov 26, 2024
10 checks passed
@Averethel Averethel deleted the chakra-v3/reference-migration branch November 26, 2024 14:39
@automotiveengineeringbot
Copy link
Collaborator

🎉 This PR is included in version 23.12.0-chakra-v3-b007baa34b3042d13cb9ebf96bd863b4c5b0e151.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@automotiveengineeringbot
Copy link
Collaborator

🎉 This PR is included in version 23.15.0-chakra-v3-f0a29c4689b248124d11f182c1701bad4af03971.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@automotiveengineeringbot
Copy link
Collaborator

🎉 This PR is included in version 23.16.0-chakra-v3-1179149485ac09b9c262ae8648e855b1ce506b02.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@automotiveengineeringbot
Copy link
Collaborator

🎉 This PR is included in version 23.16.0-chakra-v3-7a58fab7dfb141d07161cc692ea467088dbf00b4.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@automotiveengineeringbot
Copy link
Collaborator

🎉 This PR is included in version 23.17.0-chakra-v3-ed38805868813712826f68f9fd6cbcde5f1c3db6.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants