-
Notifications
You must be signed in to change notification settings - Fork 6
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
653 654 collapsible header icon keyword #676
Conversation
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 mainly have some quarrels with a few decisions that have been made, that increase code complexity. Please address these concerns.
const { children: text, prefixIcon, prefixIconColor, suffixIcon, suffixIconColor } = props; | ||
|
||
const newProps = omit( props, [ "prefixIcon", "prefixIconColor", "suffixIcon", "suffixIconColor" ] ); | ||
const { |
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 think we want to pass all these props to the button?
I suggest using object destructuring.
const {
extractedProp1,
extractedProp2,
...buttonProps
} = 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.
Also, what a godawful amount of props. Consider grouping prefix and suffix props, so you get props.suffix.icon
, props.suffix.iconColor
, and so on. I think this improved readability overall.
|
||
const newProps = omit( props, [ "prefixIcon", "prefixIconColor", "suffixIcon", "suffixIconColor" ] ); | ||
const { | ||
children: text, |
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.
You rename the children prop explicitely to text, but the propTypes
of the component suggest it can also be a element or multiple elements.
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.
No I haven't touched this part, it was already children: text
@@ -22,13 +22,14 @@ $palette_blue_dark: #084a67; // Safe to use with $palette_white – $pa | |||
$palette_green: #77b227; // Safe to use with $palette_black. | |||
$palette_green_light: #7ad03a; // Safe to use with $palette_black. | |||
$palette_green_medium_light: #64a60a; // Safe to use with $palette_black or $palette_white bold > 18.5px. | |||
$palette_green_medium: #008a00; // Safe to use with $palette_white and $palette_black. | |||
$palette_green_medium: #008a00; // Safe to use with $palette_white and $palette_black. Also used for the smiley score icon. |
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.
Shouldn't we update the color_ok
instead?
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.
color_good, color_ok: yes we can update them but worth noting they're used also in other places, for example in the content analysis and for the progress bar. If we want to update there too, that's fine I guess.
const StyledIconsButton = styled( IconsButton )` | ||
width: 100%; | ||
background-color: ${ colors.$color_white }; | ||
padding: 15px; | ||
padding: ${ props => props.headingPadding }; |
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 we should refrain from creating specific props for styling, can't we use a styled-components
way to make sure the StyledIconsButton
has the correct padding for the components that need different paddings.
prefixIconColor, | ||
suffixIcon, | ||
suffixIconColor, | ||
prefixIconViewBox, |
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.
This shouldn't exist, can't we update the SVG icon to have a 1720x1720
viewbox as well? All these iconViewbox
props are really cluttering the code. If it's not possible to change the viewbox of the icon, we should update the viewBox of the icons that require a different view box in the SvgIcon
component.
Addressed the main CR points except the color names, which I'd prefer to keep as they're for now. We can revisit when we're sure these colors should be updated globally. |
Note: as soon as this is merged, we should move #671 to the queue to adjust styling in the meta box. |
prefixIconCollapsed: PropTypes.string, | ||
prefixIconColor: PropTypes.string, | ||
prefixIconSize: PropTypes.string, | ||
prefixIcon: PropTypes.shape( { |
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.
Perhaps declare the shape seperately, and reuse this declaration wherever it's used?
Done in snippetEditorFields's descriptionLengthProgress, for instance.
Not important enough that it has to be addressed now though.
CR: ok 👍 |
Acceptance 👍 |
Summary
This PR can be summarized in the following changelog entry:
Relevant technical choices:
Collapsible
component, consequently theContentAnalysis
needed some changes toosubTitle
propAnalysisCollapsible
(this should go in the changelog) and useCollapsible
directly:AnalysisCollapsible
was duplicating 95% of the code fromCollapsible
ViewBox
: this is necessary because some icons have been coded with a different ViewBox size, thus affecting the way they're renderedContentAnalysis
and uses arenderCollapsible()
helper function to simplify codeIdeally, the
Collapsible
header component should be as style-agnostic as possible. For the header itself, it's difficult to style it independently other than passing props. Instead, the content of the collapsible should be styled independently using a specific styled component.Partially fixes also #671 which will need some adjustments in the plugin. As requested, the left and right paddings should be set on the component itself. This means the StyledSection used in the plugin should be adjusted consequently. Screenshot of the analysis in the plugin (notice the left and right paddings to reset):
Test instructions
Fixes #653
Fixes #654