Skip to content
This repository has been archived by the owner on Dec 10, 2021. It is now read-only.

feat(control-utils): add infotooltipwithtrigger #442

Merged
Show file tree
Hide file tree
Changes from 6 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions packages/superset-ui-control-utils/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -28,5 +28,10 @@
"peerDependencies": {
"@superset-ui/translation": "^0.13",
"@superset-ui/validator": "^0.13"
},
"dependencies": {
"lodash": "^4.17.15",
"react": "^16.13.1",
"react-bootstrap": "^1.0.1"
Copy link
Contributor

Choose a reason for hiding this comment

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

Re: dependencies

  1. These should be peerDependencies, as they are shared by multiple superset-ui packages and should be upgraded all at once.
  2. We are not using react-bootstrap@1 yet. It's for Bootstrap v4, but we are still stuck with Boostrap v3. Check incubator-superset for property versions for react-bootstrap and @types/react-bootstrap.
  3. Can we get rid of lodash? Is kebabCase 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.

Copy link
Member

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.

Copy link
Contributor

@kristw kristw May 6, 2020

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

Copy link
Member

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.

Copy link
Contributor

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

Copy link
Contributor

@ktmud ktmud May 6, 2020

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.

Copy link
Contributor

@kristw kristw May 6, 2020

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.

Copy link
Member

@suddjian suddjian May 6, 2020

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?

Copy link
Contributor

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?

Copy link
Member

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.

}
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
/**
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
import React from 'react';
import { kebabCase } from 'lodash';
// @ts-ignore
import { Tooltip, OverlayTrigger } from 'react-bootstrap';
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor

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

Example:
https://github.com/apache-superset/superset-ui/blob/master/packages/superset-ui-translation/types/external.d.ts

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Member

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?

Copy link
Contributor

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.


const defaultProps = {
className: 'text-muted',
icon: 'info-circle',
placement: 'right',
};
Copy link
Contributor

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.

const tooltipStyle = { wordWrap: 'break-word' } as any;
Copy link
Contributor

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={}>.

Copy link
Contributor

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.


interface Props {
label: string;
tooltip: string;
icon: string;
onClick: () => void;
placement: string;
bsStyle: string;
className: string;
}
Copy link
Contributor

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;
}

Copy link
Contributor

@kristw kristw May 6, 2020

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.

Copy link
Contributor

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.


export default function InfoTooltipWithTrigger({
kristw marked this conversation as resolved.
Show resolved Hide resolved
label,
tooltip,
icon,
className,
onClick,
placement,
bsStyle,
}: Props) {
const iconClass = `fa fa-${icon} ${className} ${bsStyle ? `text-${bsStyle}` : ''}`;
const onKeyPress = (event: React.KeyboardEvent) => {
if (event.key === 'Enter' || event.key === 'space') {
onClick();
}
};
const iconEl = (
<i
role="button"
tabIndex={0}
className={iconClass}
style={{ cursor: onClick ? 'pointer' : undefined }}
onClick={onClick}
onKeyPress={onClick && onKeyPress}
/>
);
if (!tooltip) {
return iconEl;
}
return (
<OverlayTrigger
placement={placement as any}
overlay={
<Tooltip id={`${kebabCase(label)}-tooltip`} style={tooltipStyle}>
{tooltip}
</Tooltip>
}
>
{iconEl}
</OverlayTrigger>
);
}

InfoTooltipWithTrigger.defaultProps = defaultProps;
1 change: 1 addition & 0 deletions packages/superset-ui-control-utils/src/index.ts
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,4 @@ import * as sectionModules from './sections';
export const sections = sectionModules;
export { D3_FORMAT_DOCS, D3_FORMAT_OPTIONS, D3_TIME_FORMAT_OPTIONS } from './D3Formatting';
export { formatSelectOptions, formatSelectOptionsForRange } from './selectOptions';
export { default as InfoTooltipWithTrigger } from './InfoTooltipWithTrigger';