-
Notifications
You must be signed in to change notification settings - Fork 0
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
Conversation
a227d43
to
653356b
Compare
653356b
to
f713e8e
Compare
f713e8e
to
e099ce3
Compare
import { Box, BoxProps } from '@chakra-ui/react'; | ||
export { BoxProps }; | ||
export default Box; | ||
export { Box, type BoxProps } from '@chakra-ui/react'; |
There was a problem hiding this comment.
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
src/components/index.ts
Outdated
@@ -1,2 +1,3 @@ | |||
export * from './icons'; | |||
export * from './themeProvider'; | |||
export * from './box'; |
There was a problem hiding this comment.
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
src/components/box/index.stories.tsx
Outdated
@@ -1,32 +1,31 @@ | |||
import { Meta, StoryObj } from '@storybook/react'; | |||
|
|||
import { space } from 'src/themes/shared/space'; | |||
import { sharedConfig } from 'src/themes/shared/index'; |
There was a problem hiding this comment.
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
import { Box, BoxProps } from '@chakra-ui/react'; | ||
export { BoxProps }; | ||
export default Box; | ||
export { Box, type BoxProps } from '@chakra-ui/react'; |
There was a problem hiding this comment.
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', |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 = { |
There was a problem hiding this comment.
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
@@ -0,0 +1,22 @@ | |||
import { defineTokens } from '@chakra-ui/react'; | |||
|
|||
export const aspectRatios = defineTokens.aspectRatios({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do they originate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those are chakra defaults
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
src/components/table/index.tsx
Outdated
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'; |
There was a problem hiding this comment.
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: { |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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
There was a problem hiding this 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.
1c285bb
to
4d88158
Compare
🎉 This PR is included in version 23.12.0-chakra-v3-b007baa34b3042d13cb9ebf96bd863b4c5b0e151.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 23.15.0-chakra-v3-f0a29c4689b248124d11f182c1701bad4af03971.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 23.16.0-chakra-v3-1179149485ac09b9c262ae8648e855b1ce506b02.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 23.16.0-chakra-v3-7a58fab7dfb141d07161cc692ea467088dbf00b4.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 23.17.0-chakra-v3-ed38805868813712826f68f9fd6cbcde5f1c3db6.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
Box
migrationAspectRatio
migrationGrid
migrationAdding more design tokes
Re-exporting chakra component while restricting the available props
Stack
migrationMigrating a custom component build from chakra building blocks without custom theming
MissingImage
migrationMigrating a component with defined styling
Badge
migrationMigrating a custom component with multipart styling
VehicleReference
migrationMigrating a chakra component that is now a composite component
Table
migrationHow 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