CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 78
feat: upgrade fundamental-styles to 0.4.0-rc.24 #878
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
Conversation
@@ -49,8 +49,7 @@ | |||
"@babel/runtime": "^7.8.0", | |||
"chain-function": "^1.0.1", | |||
"classnames": "^2.2.6", | |||
"fundamental-styles": "~0.4.0-rc.3", | |||
"hoist-non-react-statics": "^3.3.0", |
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.
hoist-non-react-statics should have been removed with withStyles
Deploy preview for fundamental-react ready! Built with commit f1020d1 |
Closing this for now - I'm going to upgrade to 21 since a lot of the validation states were removed between 10 and 20, but added back in 21. |
@@ -30,7 +48,8 @@ const Checkbox = React.forwardRef(({ checked, className, defaultChecked, disable | |||
|
|||
const classes = classnames( | |||
className, | |||
'fd-checkbox' | |||
'fd-checkbox', | |||
{ [`is-${state}`]: state } |
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 want to entertain this thought: Should we be defining classes with full strings instead of interpolation.
If we use string interpolation we wouldn't work with something like PurgeCSS in case a consumer wants to configure their project to minimize the imported styles.
So we'd want some utility to add the full strings here
{ ['is-warning']: state.warning, ['is-invalid']: state.invalid, ... }
PurgeCSS looks through all the imported CSS and removes the selectors that your app never uses, but it isn't smart enough to know all the values of state
that could be included in the string.
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 like the idea of this - maybe as a follow up if we want to use purgeCSS in nui-widgets/floorplans. We could go through all the components with these issues.
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 also prefer to avoid string interpolation for classnames - they don't show up in search and replaces efforts, which inevitably leads to bugs.
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 can see @bcullman's point and in our legacy applications I completely agree. However, I will say that in the world of self-contained styles, I don't think this is nearly as big of an issue anymore.
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.
Let's
@@ -33,11 +34,13 @@ FormItem.propTypes = { | |||
children: PropTypes.node, | |||
className: PropTypes.string, | |||
disableStyles: PropTypes.bool, | |||
isHorizontal: PropTypes.bool, |
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 don't love the name of this prop 🤷♀
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.
It looks like isHorizontal
puts the label and the input side-by-side on the same visual row. That seems more like isInline
to me, but I also see that prop existed before. I'm not quite sure what the difference is between isHorizontal
and isInline
. Looking at the fundamental-styles
page on forms, there are no uses of fd-form-item--inline
. 🤷♂
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.
--inline
is only for inline labels for radio and checkbox. I think we can just go forward like this, then with the rc that changes how checkboxes and radios work can revisit that?
'is-disabled': disabled, | ||
'fd-form-label--toggle': isToggle, | ||
'fd-form-label--checkbox': isCheckbox, | ||
'fd-form-label--radio': isRadio, |
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 don't really love this pattern - but checkbox and radio are going to change significantly in a couple more rc rev's so there's no point in really diving into it right now.
</Menu> | ||
} | ||
placeholder='Select Fruit' /> | ||
{...createProps()} |
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.
Going forward, it would be good to have one "default" story for each component that contains all the storybook knobs, but all additional stories should probably disable knobs as the stories really become specific use cases with all the appropriate props set and shouldn't be "played with" anymore. There are a few exceptions to this, yes, but it would be good if that was the general pattern. That said, not part of this PR.
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.
Agree! I started to do that... then realized it's soooo out of scope. What do you think about a story in the backlog to 1) upgrade storybook to use the "new" pattern we've established in floorplans 2) setup the stories consistently for the components?
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.
Yeah, that sounds like a good plan.
@@ -33,11 +34,13 @@ FormItem.propTypes = { | |||
children: PropTypes.node, | |||
className: PropTypes.string, | |||
disableStyles: PropTypes.bool, | |||
isHorizontal: PropTypes.bool, |
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.
It looks like isHorizontal
puts the label and the input side-by-side on the same visual row. That seems more like isInline
to me, but I also see that prop existed before. I'm not quite sure what the difference is between isHorizontal
and isInline
. Looking at the fundamental-styles
page on forms, there are no uses of fd-form-item--inline
. 🤷♂
'fd-radio', | ||
{ | ||
'fd-radio--compact': compact, | ||
[`is-${state}`]: state |
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.
Not exactly "self-contained", but that's a WHOLE OTHER issue.
src/Forms/Forms.Component.js
Outdated
description={`Inputs are used to collect data from the user. When a field is required, the label is displayed in bold | ||
and noted by an asterisk (*).`} | ||
description={`Inputs are used to collect data from the user. When a field is required, | ||
the <code>required</code> prop will include an asterisk (*).`} |
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 think the playground components are setup to support markdown if you didn't want to hardcode markup tags.
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.
Looks good. 🚢
Description
I was originally going to upgrade only to
0.4.0-rc.10
, but there were no additional breaking changes between0.4.0-rc.10
andrc-24
.Changes bold denotes breaking change:
FormInput
state
prop options to match new validation statesCheckbox
state
prop: added validation statesFormRadioGroup
div
to Fragment to match html from Fundamental StylesFormItem
isHorizontal
propisInline
becomes internal only prop as it is only meant for Checkboxes and RadiosFormRadioItem
compact
propstate
prop: added validation statesinline
prop becomes internal use only - should only be applied toFormRadioGroup
FormSelect
state
prop: added validation statescompact
propFormTextarea
compact
,disabled
andreadOnly
propsstate
prop: added validation statesCombobox Input
state
prop: added validation statesSearchInput
state
prop: added validation statesInputGroup
disabled
propstate
prop: added validation statescompact
prop so that appropriatefd-input-group__addon—compact
class is added to InputGroup.AddonMultiInput
placeHolder
prop toplaceholder
state
prop: added validation statesFormLabel
required
propis-Toggle
prop - internal use onlyis-Checkbox
prop - internal use onlyis-Radio
prop - internal use onlyis-InlineHelp
prop - add this to any labels used with InlineHelp componentFormMessage
TimePicker
Alert
div
for text changed top
Known Issues out of the scope of this pr: