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

Add SuperChart #68

Merged
merged 11 commits into from
Dec 20, 2018
Merged

Add SuperChart #68

merged 11 commits into from
Dec 20, 2018

Conversation

kristw
Copy link
Contributor

@kristw kristw commented Dec 17, 2018

🏆 Enhancements

  • Migrate SuperChart from incubator-superset, convert to TypeScript and add 100% unit tests.
  • Add default values for ChartProps

🏠 Internal

  • Change to export default for some modules.

@kristw kristw requested a review from a team as a code owner December 17, 2018 19:27
@kristw kristw added the WIP Work in progress label Dec 17, 2018
@codecov
Copy link

codecov bot commented Dec 17, 2018

Codecov Report

Merging #68 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master    #68   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          66     67    +1     
  Lines         669    734   +65     
  Branches      106    118   +12     
=====================================
+ Hits          669    734   +65
Impacted Files Coverage Δ
...ages/superset-ui-chart/src/models/ChartMetadata.ts 100% <ø> (ø) ⬆️
...ackages/superset-ui-chart/src/models/ChartProps.ts 100% <100%> (ø) ⬆️
...ckages/superset-ui-chart/src/models/ChartPlugin.ts 100% <100%> (ø) ⬆️
...es/superset-ui-chart/src/components/SuperChart.tsx 100% <100%> (ø)

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 556a508...e9d6e10. Read the comment docs.

@kristw kristw added the #enhancement New feature or request label Dec 17, 2018
@kristw kristw added reviewable Ready for review and removed WIP Work in progress labels Dec 18, 2018
Copy link
Contributor

@williaster williaster left a comment

Choose a reason for hiding this comment

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

lgtm, had a couple misc questions about TS.

@xtinec I think a second eye on the TS could be good still if you have time!

};
/* eslint-enable sort-keys */

type TransformFunction = (x: any) => any;
Copy link
Contributor

Choose a reason for hiding this comment

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

do you think there's any way to make this a generic? that would allow more informative typings but not sure if there's really anything meaningful we know about the arguments. they're minimally objects right? and we know pre accepts ChartProps?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will update.

overrideTransformProps?: TransformFunction;
postTransformProps?: TransformFunction;
onRenderSuccess?: HandlerFunction;
onRenderFailure?: HandlerFunction;
Copy link
Contributor

Choose a reason for hiding this comment

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

do errors have a known / consistent signature? I guess if every chart handles them differently, probably not 😢

Copy link
Contributor Author

@kristw kristw Dec 18, 2018

Choose a reason for hiding this comment

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

This one is currently hooked up for logging. And may update redux state.

) => LoadableRenderer<RenderProps, LoadedModules> | (() => null);

renderChart(loaded: LoadedModules, props: RenderProps) {
const Chart = getModule<typeof React.Component>(loaded.Chart);
Copy link
Contributor

Choose a reason for hiding this comment

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

does this require the typeof prefix? when we use it elsewhere (e.g., LoadedModules or reactify) we don't need this 🤔 wonder if it has to do with the import * as React?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does. I had <React.Component> at first and it fails.

There was a StackOverflow thread explaining it. <React.Component> will mean Chart is an instanceof React.Component but it is not what we want. Chart is a constructor that creates React.Component, not the React.Component instance, which is what <typeof React.Component> is.

id?: string;
className?: string;
} = {};
if (id) {
Copy link
Contributor

Choose a reason for hiding this comment

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

does this complain if you set it as this?

const containerProps: {
  id?: string;
  className?: string;
} = { id, className };

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This might still create <div id="" className=""> eventhough id and className are undefined. The if condition ensure it will be just <div>, which is slightly cleaner.

@kristw kristw requested a review from xtinec December 18, 2018 21:18
describe('SuperChart', () => {
it('does not render if chartType is not set', done => {
const wrapper = shallow(<SuperChart />);
setTimeout(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm, it seems we only need setTimeout when testing the slow chart, right?


const EMPTY = () => null;

/* eslint-disable sort-keys */
Copy link
Contributor

Choose a reason for hiding this comment

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

Might be worth-while disabling sort-keys in our build-config.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah I have mixed feelings on that rule, it's a pain sometimes esp when you want to logically group things like this. I'll make the change in build-config.

Copy link
Contributor

Choose a reason for hiding this comment

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

👍

@@ -62,28 +62,28 @@ describe('SuperChart', () => {
setTimeout(() => {
expect(wrapper.render().find('div.test-component')).toHaveLength(1);
done();
}, 5);
}, 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

We could remove setTimeout altogether on all except for slow charts, perhaps?

expect(...);
done();

Copy link
Contributor Author

Choose a reason for hiding this comment

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

tried and it fails tests if I remove setTimeout. This might be something to do with react-loadable

Copy link
Contributor

Choose a reason for hiding this comment

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

I've found that sometimes setTimeout(fn, 0) is needed to get to the next tick for some lifecycle or mount-based functionality.

Copy link
Contributor

Choose a reason for hiding this comment

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

Interesting that the "requeueing" of fn is necessary sometimes. We can leave this as-is then.

chartProps?: ChartProps | null;
chartType: string;
preTransformProps?: TransformFunction<ChartProps>;
overrideTransformProps?: TransformFunction;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should both overrideTransformProps and postTransformProps take ChartProps as type arguments?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If preTransformProps transforms ChartProps into something else, that will be input to overrideTransformProps and/or postTransformProps

Copy link
Contributor

Choose a reason for hiding this comment

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

That's true. I suppose we could create a generic over the output props and use that as the input for overrideTransformProps and postTransformProps.

I'm cool leaving this as-is for now (perhaps adding a TODO to revisit?). Think we could potentially improve the types here once we have more chart plugins added.

@xtinec xtinec merged commit 9c48747 into master Dec 20, 2018
@delete-merged-branch delete-merged-branch bot deleted the kristw--super-chart branch December 20, 2018 20:32
@kristw kristw added this to the v0.8.0 milestone Feb 1, 2019
kristw added a commit that referenced this pull request Apr 17, 2020
* fix: fallback to default margin when margin is partially set

* feat: can disable axis title

* feat: adjust margin according to axis title visibility

* feat: include margin in formData

* feat: add buildQuery

* fix: address kyle comments

* fix: remove string false

* fix: line chart temporal scale

* fix: format
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
#enhancement New feature or request reviewable Ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants