-
Notifications
You must be signed in to change notification settings - Fork 272
Conversation
Codecov Report
@@ Coverage Diff @@
## master #68 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 66 67 +1
Lines 669 734 +65
Branches 106 118 +12
=====================================
+ Hits 669 734 +65
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.
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; |
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.
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 object
s right? and we know pre accepts ChartProps
?
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.
Will update.
overrideTransformProps?: TransformFunction; | ||
postTransformProps?: TransformFunction; | ||
onRenderSuccess?: HandlerFunction; | ||
onRenderFailure?: HandlerFunction; |
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.
do errors have a known / consistent signature? I guess if every chart handles them differently, probably not 😢
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.
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); |
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.
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
?
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.
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) { |
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.
does this complain if you set it as this?
const containerProps: {
id?: string;
className?: string;
} = { id, className };
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.
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.
describe('SuperChart', () => { | ||
it('does not render if chartType is not set', done => { | ||
const wrapper = shallow(<SuperChart />); | ||
setTimeout(() => { |
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.
hmm, it seems we only need setTimeout
when testing the slow chart, right?
|
||
const EMPTY = () => null; | ||
|
||
/* eslint-disable sort-keys */ |
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-while disabling sort-keys
in our build-config
.
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.
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.
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.
👍
@@ -62,28 +62,28 @@ describe('SuperChart', () => { | |||
setTimeout(() => { | |||
expect(wrapper.render().find('div.test-component')).toHaveLength(1); | |||
done(); | |||
}, 5); | |||
}, 0); |
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.
We could remove setTimeout
altogether on all except for slow charts, perhaps?
expect(...);
done();
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.
tried and it fails tests if I remove setTimeout
. This might be something to do with react-loadable
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've found that sometimes setTimeout(fn, 0)
is needed to get to the next tick for some lifecycle or mount-based functionality.
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.
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; |
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.
Should both overrideTransformProps
and postTransformProps
take ChartProps
as type arguments?
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 preTransformProps
transforms ChartProps
into something else, that will be input to overrideTransformProps
and/or postTransformProps
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.
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.
* 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
🏆 Enhancements
SuperChart
fromincubator-superset
, convert to TypeScript and add 100% unit tests.ChartProps
🏠 Internal
export default
for some modules.