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

refactor: Bootstrap to AntD - Button #12832

Merged
merged 1 commit into from
Feb 1, 2021

Conversation

michael-s-molina
Copy link
Member

@michael-s-molina michael-s-molina commented Jan 29, 2021

SUMMARY

  • Migrates Button component from Bootstrap to AntD.
  • Removes unused properties.
  • Unifies button sizes (default, small and xsmall).
  • Improves gallery and interactive panel in Storybook.
  • Changes Button Storybook to use typescript.
  • Improves focus perception on secondary and warning buttons.
  • Changes cursor to not-allowed when disabled.
  • Adjusts buttons spacing to 2x grid-unit instead of 4x grid-unit in listings following the same style as other parts of the application (modals, query editor, etc).
  • Adjust buttons in welcome page to the same height.
  • Replaces Bootstrap ButtonGroup with internal component.
  • Creates a ButtonGroup storybook.
  • Creates a ButtonGroup test suite.

See: #10254

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Screen Shot 2021-01-29 at 10 52 43 AM

Screen Shot 2021-01-29 at 11 27 09 AM

Screen Shot 2021-01-29 at 10 53 13 AM

Screen Shot 2021-01-29 at 11 27 29 AM

Screen Shot 2021-01-29 at 10 56 12 AM

Screen Shot 2021-01-29 at 11 28 12 AM

Screen Shot 2021-01-29 at 10 53 28 AM

Screen Shot 2021-01-29 at 11 27 42 AM

Screen Shot 2021-01-29 at 10 56 55 AM

Screen Shot 2021-01-29 at 11 28 31 AM

Screen Shot 2021-01-29 at 10 58 27 AM

Screen Shot 2021-01-29 at 11 28 49 AM

@rusackas @junlincc All changes described here had to be made in a single PR because they are all correlated.

TEST PLAN

1 - Open any screen that contains a button (explore, welcome, dashboards, etc.)
2 - All buttons should have the same theme and behavior
3 - Additional testing can be done using Storybook

ADDITIONAL INFORMATION

  • Has associated issue:
  • Changes UI
  • Requires DB Migration.
  • Confirm DB Migration upgrade and downgrade tested.
  • Introduces new feature or API
  • Removes existing feature or API

@codecov-io
Copy link

codecov-io commented Jan 29, 2021

Codecov Report

Merging #12832 (144b26d) into master (bab86ab) will decrease coverage by 1.64%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #12832      +/-   ##
==========================================
- Coverage   65.05%   63.40%   -1.65%     
==========================================
  Files        1021      488     -533     
  Lines       50095    30173   -19922     
  Branches     5141        0    -5141     
==========================================
- Hits        32587    19132   -13455     
+ Misses      17332    11041    -6291     
+ Partials      176        0     -176     
Flag Coverage Δ
cypress ?
javascript ?
python 63.40% <ø> (-0.67%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
superset/db_engines/hive.py 0.00% <0.00%> (-85.72%) ⬇️
superset/sql_validators/postgres.py 50.00% <0.00%> (-50.00%) ⬇️
superset/db_engine_specs/hive.py 73.84% <0.00%> (-17.31%) ⬇️
superset/databases/commands/create.py 83.67% <0.00%> (-8.17%) ⬇️
superset/databases/commands/update.py 85.71% <0.00%> (-8.17%) ⬇️
superset/connectors/sqla/models.py 84.31% <0.00%> (-6.28%) ⬇️
superset/db_engine_specs/sqlite.py 90.62% <0.00%> (-6.25%) ⬇️
superset/databases/commands/test_connection.py 84.78% <0.00%> (-4.35%) ⬇️
superset/utils/celery.py 86.20% <0.00%> (-3.45%) ⬇️
superset/models/core.py 85.59% <0.00%> (-3.27%) ⬇️
... and 524 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bab86ab...144b26d. Read the comment docs.

import Button from 'src/components/Button';
import ButtonGroup from './index';

export default {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe a minor thing, but I kind of prefer named exports to default exports. I'm not sure where this pattern is going to settle in Superset, but I like that named imports are typically easier to search for in the codebase.

Copy link
Member Author

Choose a reason for hiding this comment

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

@rusackas In this specific case I'm using default export following Storybook documentation:

The default export defines metadata about your component, including the component itself, its title (where it will show up in the navigation UI story hierarchy), decorators, and parameters.

Now looking at the rest of the application, I prefer named exports also but currently the majority of our components are using default exports and the screens using them are importing using component's folder name. Let me describe here how I'm going to tackle this:

  • First I'm going to remove the difference between common components and components. All will be components with their own folder, storybook and test. For this step, I will preserve current standard and use default exports.
  • Remove Bootstrap dependency
  • After all components are following the same structure, we will create an index in components folder exporting our version of the components using named exports. That way we'll import our version using import { Component } from 'src/components';
  • Changing the code to use named exports will be done in a specific PR.

options: {
Superset: 'http://https://superset.apache.org/',
None: null,
superset: 'https://superset.apache.org/',
Copy link
Member

Choose a reason for hiding this comment

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

I have no strong feelings about the capitalization here, but I wonder if we should stick to the Superset caps rules (Sentence case) or if there's a rationale behind switching to lower case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Here I made a conscious change because those are properties and should appear as such in controls panel. It's the same as reading an API. In fact, if we don't specify names for properties, Storybook will automatically create them using lower case.

@@ -296,8 +296,8 @@ class PropertiesModal extends React.PureComponent {
footer={
<>
<Button
type="button"
buttonSize="sm"
htmlType="button"
Copy link
Member

Choose a reason for hiding this comment

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

This seems fine, but I'm curious if/why we need it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Me too 😄! I just changed type to htmlType. I think the developer wanted to make it clear that he's handling the submit.

onClick={onSave}
data-test="query-save-button"
<div
css={{
Copy link
Member

Choose a reason for hiding this comment

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

this is fine by me, but curious as to why you prefer the <div css={{... approach over the styled.div approach. They both seem to meet the same goal, so just wondering :D

Copy link
Member Author

Choose a reason for hiding this comment

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

For me the use of a property seems more natural to the objective of customizing a component. Here you will find a detailed explanation but to summarize:

  • You’re still writing regular React components
  • Object styles are easier to work with
  • Naming things is hard
  • You colocate styles with elements
  • Composition is dead easy

<IconContainer>
<Icon name="plus-small" />
<div>
<i className="fa fa-plus" />
Copy link
Member

Choose a reason for hiding this comment

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

A little sad about moving away from the custom icon to the font-awesome one, but I see why you're trying to whittle out the weird div.

@geido should we just not worry about this for now, and tackle it after your icon work goes through?

Copy link
Member

Choose a reason for hiding this comment

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

Sure 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok. Here is the problem. We have a lot of places where a button is defined with a nested <i> element referencing an icon. These icons don't have any margin or padding, it's the real icon size. That's why this code here in Button automatically creates a margin between the icon and the text:

'i:first-of-type, svg:first-of-type': {
   marginRight: theme.gridUnit * 2,
   padding: `0 ${theme.gridUnit * 2} 0 0`,
},

The Icon component have a predefined viewBox of 24x24, so that margin is not required. I could replace all <i> elements with the Icon component and remove the margin but as you mentioned @geido is already working on that. So I think the safest path is to make this modification in Icon PR and also remove Button automatic margin there.

<Icon name="plus-small" /> Dashboard{' '}
</IconContainer>
<div>
<i className="fa fa-plus" /> Dashboard{' '}
Copy link
Member

Choose a reason for hiding this comment

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

Same here... would prefer to use our custom icons if possible, but those are being revamped presently

Copy link
Member Author

Choose a reason for hiding this comment

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

Same as previous comment.

.slice(0, tableName.length - 1)
.join('')}
<i className="fa fa-plus" />
{tableName === 'SAVED_QUERIES'
Copy link
Member

Choose a reason for hiding this comment

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

same about fontawesome

Copy link
Member Author

Choose a reason for hiding this comment

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

Same as previous comment.

Copy link
Member

@rusackas rusackas left a comment

Choose a reason for hiding this comment

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

This is an AMAZING PR. Added some minor questions/curiosities, with maybe a slight concern about moving bakcward from custom icons to font-awesome. Looking absolutely fantastic in general, this is great stuff.

Copy link
Member

@rusackas rusackas left a comment

Choose a reason for hiding this comment

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

Thanks for the clarifications @michael-s-molina - I think we can merge this as-is and then sweep through all buttons containing icons for consistency once @geido 's Icon PR is also merged.

@rusackas rusackas merged commit c781ab8 into apache:master Feb 1, 2021
@junlincc junlincc added risk:migration High risk PR, wait for(at least) a week to deploy after merging and removed risk:migration High risk PR, wait for(at least) a week to deploy after merging labels Feb 3, 2021
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 1.2.0 labels Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels size/XXL 🚢 1.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants