feat(DrawerContent): removed no-background colorVariant #629
Conversation
thatblindgeye
force-pushed
the
iss624_drawerColorVariant
branch
from
3cb6c45 to
2977e1d
Compare
|
|
||
| The "no-background" value of the `colorVariant` prop on DrawerContent has been removed, and a new "primary" value has been added. | ||
|
|
||
| Additionally, a new DrawerContentColorVariant enum has been added and should be used instead of the DrawerColorVariant enum. The fix when the DrawerColorVariant enum is being used will replace the `colorVariant` prop value with a string. |
There was a problem hiding this comment.
Just a note, the logic in the rule for this part will cause the drawerReplaceColorVariantLight200 rule output file to be updated further because of this (current output has the second DrawerContent updated to colorVariant={DrawerColorVariant.secondary}, this rule will cause the output to be updated to colorVariant="secondary". I can remove this logic if we want to avoid that, or I can update the input/output files to prevent the update from happening every time.
There was a problem hiding this comment.
I am OK with this rule updating the drawerReplaceColorVariantLight200 output example. Something similar happens with the chipReplaceWithLabel updating the output of chipDeprecated. We just should be careful of which files are we adding to commits, so we accidentally don't change these output files on the "production" branch.
...werContentReplaceNoBackgroundColorVariant/drawerContent-replace-noBackground-colorVariant.ts
Outdated
Show resolved
Hide resolved
...werContentReplaceNoBackgroundColorVariant/drawerContent-replace-noBackground-colorVariant.ts
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| const variableInit = variableDeclaration.defs.length | ||
| ? variableDeclaration.defs[0].node.init |
There was a problem hiding this comment.
Can we check that the type of variableDeclaration.defs[0] equals to "Variable" here? It will then also make the type of variableInit not being any, because the node will be treated as node: VariableDeclarator.
EDIT: after checking it further, it will create some type problems when accessing colorVariantValue.object or colorVariantValue.property, because the colorVariantValue won't have the value of any anymore. So some additional functionality for checking if the return value is of type MemberExpression would be needed.
There was a problem hiding this comment.
We can open a followup to address this if you'd like.
There was a problem hiding this comment.
Sure. It probably won't cause any problems for now, since I cannot imagine someone would be passing a function name (or anything other than a variable name) as an attribute value.
Opened a followup issue: #630
thatblindgeye
force-pushed
the
iss624_drawerColorVariant
branch
from
d127673 to
f8521a2
Compare
Closes #624
Also types findVariableDeclaration helper and adds some other helpers.