-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Change type of graphicalItems from any to ReadonlyArray<ReactElement> #3844
Conversation
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, just one question on the class thing
@@ -146,7 +146,7 @@ export class Bar extends PureComponent<Props, State> { | |||
offset, | |||
}: { | |||
props: Props; | |||
item: Bar; |
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.
was Bar
referencing the class in this case? :o. Is that not still more accurate than a generic ReactElement?
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.
Could we do ReactElement<BarProps>
to give the needed specificity?
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.
So two answers, one short term (this PR) one long term (recharts future).
Short term: Yes, using Bar
is more accurate. But it is only accurate on the receiving end! In the sending end there is no guarantee. generateCategoricalChart
sends ReactElement. So this was a false positive, going against Barbara Liskov principle.
Long term: In my opinion, architecture where a component requires a rendered instance of itself to look up in the global state before it decides if it can render - is not a good architecture. This whole function should be different and this argument should not exist.
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.
Agreed with the long term for sure, one of the major issues with why generateCategoricalChart is how it is.
Unfortunate that short term we can't have some sort of guarantee of what we're receiving, but I guess that's just the cards we've been deal with this little mess.
Thanks
@@ -874,6 +874,7 @@ export const generateCategoricalChart = ({ | |||
(axisMap && axisMap[id]) || entry.axisType === 'zAxis', | |||
`Specifying a(n) ${entry.axisType}Id requires a corresponding ${ | |||
entry.axisType | |||
// @ts-expect-error we should stop reading data from ReactElements |
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.
💯% agree, the data has to come from somewhere though. Eventually, we refactor this to get the data from... well data instead of elements 😅. In the meantime the invariant is still useful with the expect error
Description
Types!
Related Issue
#3717
Motivation and Context
Types
How Has This Been Tested?
TS, Jest
Screenshots (if appropriate):
Types of changes
Checklist: