Skip to content
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

refactor: Migration of Chart to TypeScript #28370

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

EnxDev
Copy link
Contributor

@EnxDev EnxDev commented May 7, 2024

SUMMARY

Migrate Chart to TypeScript

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N.A.

TESTING INSTRUCTIONS

  • All tests should pass

ADDITIONAL INFORMATION

  • Has associated issue:
  • Required feature flags:
  • Changes UI
  • Includes DB Migration (follow approval process in SIP-59)
    • Migration is atomic, supports rollback & is backwards-compatible
    • Confirm DB migration upgrade and downgrade tested
    • Runtime estimates and downtime expectations provided
  • Introduces new feature or API
  • Removes existing feature or API

};
export interface ChartProps {
annotationData?: object;
actions: any;
Copy link
Member

Choose a reason for hiding this comment

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

Can we use more specific types? In general we try to avoid using very generic types like any or object

Copy link
Contributor Author

@EnxDev EnxDev May 9, 2024

Choose a reason for hiding this comment

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

For the annotation property, I believe the interface I created in this PR should be suitable.
For the actions property I created a type.

What do you think about that?

Co-authored-by: Kamil Gabryjelski <kamil.gabryjelski@gmail.com>
class Chart extends React.PureComponent<ChartProps, {}> {
static defaultProps = defaultProps;

renderStartTime: any;
Copy link
Member

Choose a reason for hiding this comment

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

Where does renderStartTime come from? In the old version, we're only reading it, but we don't assign any value to it. In your changes you put renderStartTime in ChartProps, but also as class's field. I don't think it's actually passed as a prop anywhere, and as a class field it's also only read, not assigned.
So maybe we should just remove it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed this from ChartProps.
You mean we should remove him from line 198 and 200 ( start_offset and duration keys)?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, unless I misunderstand something here, renderStartTime is always undefined because we don’t set its value anywhere, so maybe we could remove it from the code. @rusackas any objections?

Copy link
Member

Choose a reason for hiding this comment

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

Unless we want to actually fix it and assign a timestamp

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I think we should understand why it was put there.
I remain waiting for instructions, thank you.

Copy link
Member

Choose a reason for hiding this comment

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

Well, if it's not wired up, that's an odd problem. It sure seems like it'd be useful for logging, which seems to be its intent. There's one in ChartRenderer.jsx that IS wired up, for reference. Maybe we don't need both though?

It WAS set in the original commit, actually. I haven't checked to see when its initialization was removed but clearly there wasn't much outcry.

I'd err on the side of more logging, not less. Maybe @eschutho would be interested in taking more advantage of this insight :)

Copy link
Member

@geido geido May 16, 2024

Choose a reason for hiding this comment

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

No any please

Copy link
Member

@kgabryje kgabryje left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! Added a few comments

@@ -214,7 +209,7 @@ class Chart extends React.PureComponent<ChartProps, {}> {
});
}

renderErrorMessage(queryResponse: queryResponse) {
renderErrorMessage(QueryResponse: QueryResponse) {
Copy link
Member

Choose a reason for hiding this comment

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

The argument should be lowercase, only the type is PascalCase

Copy link
Member

Choose a reason for hiding this comment

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

Does not look like this was resolved

EnxDev and others added 2 commits May 9, 2024 09:01
onQuery?: MouseEventHandler<HTMLSpanElement>;
onFilterMenuOpen?: Function;
onFilterMenuClose?: Function;
ownState?: any;
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a better type for this?

@@ -214,7 +209,7 @@ class Chart extends React.PureComponent<ChartProps, {}> {
});
}

renderErrorMessage(queryResponse: queryResponse) {
renderErrorMessage(QueryResponse: QueryResponse) {
Copy link
Member

Choose a reason for hiding this comment

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

Does not look like this was resolved

@@ -201,7 +238,7 @@ class Chart extends React.PureComponent {
});
}

renderErrorMessage(queryResponse) {
renderErrorMessage(QueryResponse: QueryResponse) {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
renderErrorMessage(QueryResponse: QueryResponse) {
renderErrorMessage(queryResponse: QueryResponse) {

emitCrossFilters?: boolean;
}

export type QueryResponse = {
Copy link
Member

Choose a reason for hiding this comment

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

This assumes that the response will always be an error. I think we already have a correct type for this. We either need to adjust that to account for the error or create one specifically for when get an error:

Instead of this QueryResponse see: superset-frontend/packages/superset-ui-core/src/query/types/QueryResponse.ts ChartDataResponse

For the error maybe superset-frontend/packages/superset-ui-core/src/query/getClientErrorObject.ts ClientErrorObject

class Chart extends React.PureComponent<ChartProps, {}> {
static defaultProps = defaultProps;

renderStartTime: any;
Copy link
Member

@geido geido May 16, 2024

Choose a reason for hiding this comment

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

No any please

Comment on lines +29 to +33
subtitle: JSX.Element;
copyText: string;
link?: string;
source: ChartSource;
stackTrace?: string;
Copy link
Member

Choose a reason for hiding this comment

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

I believe this could be an extension of superset-frontend/packages/superset-ui-core/src/query/getClientErrorObject.ts ClientErrorObject

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants