-
Notifications
You must be signed in to change notification settings - Fork 271
feat(control-utils): add infotooltipwithtrigger #442
feat(control-utils): add infotooltipwithtrigger #442
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/superset/superset-ui/73baqpif1 |
Codecov Report
@@ Coverage Diff @@
## master #442 +/- ##
=========================================
+ Coverage 3.08% 3.20% +0.12%
=========================================
Files 151 152 +1
Lines 5218 5238 +20
Branches 273 275 +2
=========================================
+ Hits 161 168 +7
- Misses 5020 5033 +13
Partials 37 37
Continue to review full report at Codecov.
|
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.
Thanks for doing this. Added a couple of comments on style nits.
I'm not sure we want to put this under control-utils
, though, as this seems to be a fairly generic component that is used in more than chart controls.
I feel we kind of need a generic UI library + an arsenal of library-agnostic chart controls to better prepare for future migration.
"dependencies": { | ||
"lodash": "^4.17.15", | ||
"react": "^16.13.1", | ||
"react-bootstrap": "^1.0.1" |
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.
Re: dependencies
- These should be
peerDependencies
, as they are shared by multiplesuperset-ui
packages and should be upgraded all at once. - We are not using
react-bootstrap@1
yet. It's for Bootstrap v4, but we are still stuck with Boostrap v3. Checkincubator-superset
for property versions forreact-bootstrap
and@types/react-bootstrap
. - Can we get rid of
lodash
? IskebabCase
absolutely necessary? Could you investigate why do we needed an ID for the tooltip in the first place? It's the best if we could just remove it. Less dependencies the better.
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.
Regarding 3, I think that kind of effort is better left until after we've moved things from superset. This should be as clean a refactor as possible, just moving code into superset-ui.
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.
react
in particular should always be peerDependencies
in any library. There should always be one react
.
react-bootstrap
can be left in dependencies
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 don't agree with making these peer dependencies, because the code directly depends on them. Peer dependencies aren't meant to be used for optimization, npm does that automatically when version numbers of dependencies are compatible with each other.
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 agree with making them dependencies
as-is except react
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.
True, npm might be able to remove duplicates, but I think there is also the implication of what if it is not compatible? Are we really OK with having multiple versions of the dependent libraries in our app?
These superset-ui
packages cannot work outside of Superset or Superset UI demos, so they should not introduce their own large non-optional dependencies. Using peerDependencies
kind of forces package maintainers and library users to keep the dependencies up to date.
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.
True, npm might be able to remove duplicates, but I think there is also the implication of what if it is not compatible? Are we really OK with having multiple versions of the dependent libraries in our app?
I think that is how all packages work tho. I am ok having multiple versions of the dependent instead of worrying about breaking anything if bump version of one dependencies.
These superset-ui packages cannot work outside of Superset or Superset UI demos, so they should not introduce their own large non-optional dependencies. Using peerDependencies kind of forces package maintainers to keep the dependencies up to date.
This is actually not entirely correct. These packages can work outside of Superset and Superset UI demos. They are independent packages on their own (number format, time format, color, etc.) which do not need Superset to function. I have them as dependencies in other projects and have always think of them independent from incubator-superset
. They should have their own dependencies.
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.
All other superset-ui packages have things (including lodash) listed under dependencies
. Is this different somehow?
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 am proposing we proceed with moving react
to peerDependencies
and leave the remaining in dependencies
unless there is objection?
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 objection here. I actually already moved react, but haven't pushed it yet.
icon: 'info-circle', | ||
placement: 'right', | ||
}; | ||
const tooltipStyle = { wordWrap: 'break-word' } as any; |
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.
Try avoid any
if possible:
const tooltipStyle: React.CSSProperties = { wordWrap: 'break-word' };
Since this rule is so simple, you can probably also just inline the style in <Tooltip ... style={}>
.
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.
having constant here is better so react won't re-render. when passing object to style
, react
only compares reference.
import React from 'react'; | ||
import { kebabCase } from 'lodash'; | ||
// @ts-ignore | ||
import { Tooltip, OverlayTrigger } from 'react-bootstrap'; |
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.
Prefer to remove // @ts-ignore
and add proper typing support by installing @types/react-bootstrap
.
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 I remember correctly, bootstrap 3 doesn't have types support. We ran into this problem in incubator-superset as well.
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.
Instead of @ts-ignore, you can add a declaration file. Even if it is an empty declaration
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 @types/react-bootstrap @ 0.32.2
works with Bootstrap v3. There might be cases with suboptimal typings, where you can then do @ts-ignore
per module.
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.
Nice! That means we can add types for bootstrap back in incubator-superset too
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.
@ktmud I tried adding the types for bootstrap, but that leads to an issue in CI. It looks like our version of typescript isn't happy with those type definitions, any ideas on how to fix?
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.
Sorry, should've used @types/react-bootstrap @ ^0.32.21
. This is also what's used in incubator-superset
.
Btw, it's preferable to have @types/*
in dependencies
instead of devDependencies
so that dependent packages can have easier access to typings when the library is used in npm link
.
className: 'text-muted', | ||
icon: 'info-circle', | ||
placement: 'right', | ||
}; |
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.
Prefer to use ES6 function argument defaults.
placement: string; | ||
bsStyle: string; | ||
className: 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.
Make those with defaults optional.
interface Props {
label: string;
icon: string;
tooltip?: string;
onClick?: () => void;
placement?: string;
bsStyle?: string;
className?: 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.
+1 @ktmud with the small change to use type
for Props
instead of interface
. (Just convention from guidelines at Airbnb and used throughout the codebase at the moment). Also export
the type.
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.
interface
means the properties are immutable which often runs into problems when you want to extend the component and override the prop types.
Please also add unit test to ensure 100% coverage |
Addressed PR feedback, should be ready for a re-review |
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! Thanks to all involved for giving this so much due diligence.
🏆 Enhancements
Adding infotooltipwithtrigger to superset ui. This is required for migrating partition chart control panels.