-
Notifications
You must be signed in to change notification settings - Fork 14k
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: Replace react-bootstrap Tabs with Antd Tabs in DashboardBuilder #11160
Conversation
@rusackas Can you please take a look? |
Should we use the other style of antd tabs instead of these? Looks like antd offers 2-3 different looks here https://ant.design/components/tabs/. Let's get designer input on which one to use here and elsewhere. |
@mistercrunch I think it's a great idea to ask for a designer's input, but let's keep in mind that in the case of editable tabs (with add and remove options) we have no choice and we need to use the "card" style. However in the case of non-editable tabs we can use either "line" or "card" style. |
Depending on designers input, we may be able to switch the tab style in edit/view mode if necessary too. @kgabryje is it because the "non-card" tabs don't allow for arbitrary React node? They force you to pass a string? |
Contrary to react-bootstrap tabs, here we use Antd's native functionality of adding and removing tabs, and it's required to pass |
@kgabryje I posed this question to designers (admittedly, internal ones... the broader community is welcome to engage here!), and got some feedback: The technical constraints, requiring the use of the card-style tabs here are acknowledged. The design perspective, however, is that we should limit the number of visible tab styles in our design system. The preferred approach would be to use these card-based tabs, but restyle them so they have a more consistent appearance with the underlined tabs we use elsewhere. I don't believe it should block this PR, as I think this PR is a big step in the right direction. A PR in which we re-style the various AntD tab flavors to be more consistent seems like a worthy follow-up task. Curious how others feel about that proposal. |
Not a designer, but I also feel the original design is a cleaner and better user experience. It'd be a little weird to have different visual styles (line vs card) for tabs in View and in Edit modes. In general, we should probably limit style changes when replacing Bootstrap components. For this case, it'd be easier and less risky if we had just kept the original editing functionalities and only replaced the |
Codecov Report
@@ Coverage Diff @@
## master #11160 +/- ##
==========================================
- Coverage 66.58% 59.21% -7.37%
==========================================
Files 873 830 -43
Lines 41767 40206 -1561
Branches 3827 3577 -250
==========================================
- Hits 27809 23807 -4002
- Misses 13856 16231 +2375
- Partials 102 168 +66
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
.dashboard-component.dashboard-component-header .anchor-link-container { | ||
.fa.fa-link { | ||
font-size: @font-size-l; | ||
} | ||
} | ||
|
||
.nav.nav-tabs li:hover, | ||
.ant-tabs-nav-list .ant-tabs-tab { |
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.
Would much rather see this moved into Emotion, in the Tabs
component, and using gridUnit * 3
instead of 12
@@ -113,7 +108,7 @@ describe('Tabs', () => { | |||
const createComponent = sinon.spy(); | |||
const wrapper = setup({ editMode: true, createComponent }); | |||
wrapper | |||
.find('.dashboard-component-tabs .nav-tabs a') | |||
.find('.dashboard-component-tabs .ant-tabs-nav-add') |
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.
might be worth considering a data-test attribute here, in case our class names change for library/styling purposes.
<WithDragDropContext> | ||
<Tabs {...props} {...overrideProps} /> | ||
</WithDragDropContext> | ||
<ThemeProvider theme={supersetTheme}> |
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'd rather not import the supersetTheme
and ThemeProvider
to use here, you can instead import { styledMount as mount } from 'spec/helpers/theming'
and then just do
<Provider store={mockStoreWithTabs}>
<WithDragDropContext>
<Tabs {...props} {...overrideProps} />
</WithDragDropContext>
</Provider>
In the last conversation I had with designers about this, the conclusion was: Any objections to the above? |
Thank you, I'll restyle the tabs to make them look more like "line" style tabs. |
I did a rebase to resolve conflicts. Also, I moved styled from |
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 to me, happy to merge if others' concerns are addressed.
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.
LGTM
…lder (apache#11160) * Replace tabs in DashboardBuilder * Fix tests * Fix styling of anchor * Fix * Fix cypress test * Fix tests * Fix e2e tests * Use data-tests * Move tabs styles from superset.less to Emotion * Restyle tabs in DashboardBuilder * Test fix * Fix styling
SUMMARY
This PR replaces usages of
react-bootstrap
's Tabs component with tabs fromantd
in DashboardBuilder. As you can see on the gifs, besides the new look I also removed the popover with delete button. Now it should be more intuitive.On the downside, drag'n'drop functionality is a bit less handy - you need to drag a tab to the edge of another tab's title rather than the edge of tab itself. It worked the same in the old version, but due to different UI it was more noticeable. Changing this behaviour would require a major refactor - I think we should do it, but as a part of a different task/PR.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:
After:
TEST PLAN
ADDITIONAL INFORMATION