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

feat(fe): upgrade superset-frontend to Typescript v5 #31979

Merged

Conversation

hainenber
Copy link
Contributor

@hainenber hainenber commented Jan 24, 2025

feat(fe): upgrade superset-frontend to Typescript v5

SUMMARY

Refactor the whole superset-frontend codebase to be compatible with Typescript v5. Most changes are simply casting index key to proper signature, i.e. a as keyof typeof B and defining Record types. However, there are a few hard roadblocks that I had to rely on //@ts-ignore to bypass; I have added explanation for each of them.

Sanity testing from 1st glance looks OK

image image

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

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

Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
Copy link

korbit-ai bot commented Jan 24, 2025

Based on your review schedule, I'll hold off on reviewing this PR until it's marked as ready for review. If you'd like me to take a look now, comment /korbit-review.

Your admin can change your review schedule in the Korbit Console

Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
…alue assignment

Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
@hainenber hainenber marked this pull request as ready for review January 28, 2025 13:54
@dosubot dosubot bot added change:frontend Requires changing the frontend frontend:refactor Related to refactoring the frontend labels Jan 28, 2025
@hainenber
Copy link
Contributor Author

/korbit-review

Copy link

@korbit-ai korbit-ai bot left a comment

Choose a reason for hiding this comment

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

Review by Korbit AI

Korbit automatically attempts to detect when you fix issues in new commits.
Category Issue Fix Detected
Functionality Incorrect Type Return with Optional ID ▹ view
Functionality Zero Value Edge Case in Bubble Size Normalization ▹ view
Functionality Incorrect Type Union in Native Filters Reduction ▹ view
Functionality Incorrect Type Assertion in QueryEditor Accumulator ▹ view
Functionality Overly Restrictive Field Type Casting for className ▹ view
Functionality Incorrect Field Type Casting for helpText ▹ view
Functionality Unsafe numeric conversion in comparator ▹ view
Functionality Lost Hover State Functionality ▹ view
Functionality Potentially Breaking Optional Values Property ▹ view
Functionality Invalid tagIds Type Union ▹ view

Need a new review? Comment /korbit-review on this PR and I'll review your latest changes.

Korbit Guide: Usage and Customization

Interacting with Korbit

  • You can manually ask Korbit to review your PR using the /korbit-review command in a comment at the root of your PR.
  • You can ask Korbit to generate a new PR description using the /korbit-generate-pr-description command in any comment on your PR.
  • Too many Korbit comments? I can resolve all my comment threads if you use the /korbit-resolve command in any comment on your PR.
  • Chat with Korbit on issues we post by tagging @korbit-ai in your reply.
  • Help train Korbit to improve your reviews by giving a 👍 or 👎 on the comments Korbit posts.

Customizing Korbit

  • Check out our docs on how you can make Korbit work best for you and your team.
  • Customize Korbit for your organization through the Korbit Console.

Feedback and Support

superset-frontend/src/dashboard/types.ts Outdated Show resolved Hide resolved
helpText={FIELD_TEXT_MAP[field].helpText}
label={FIELD_TEXT_MAP[field].label || field}
placeholder={FIELD_TEXT_MAP[field as FieldTextMapKey].placeholder}
helpText={FIELD_TEXT_MAP[field as 'account']?.helpText}
Copy link

Choose a reason for hiding this comment

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

Incorrect Field Type Casting for helpText category Functionality

Tell me more
What is the issue?

The field type is incorrectly cast to only 'account', which means helpText will only be available for account fields even when it might be needed for other field types.

Why this matters

This will cause helpText to be undefined for all fields except 'account', potentially hiding important help information from users for other field types.

Suggested change ∙ Feature Preview

Change the type casting to use FieldTextMapKey like other properties:

helpText={FIELD_TEXT_MAP[field as FieldTextMapKey]?.helpText}

💡 Does this comment miss the mark? Tell us why and Korbit will adapt to your team’s feedback.
💬 Chat with Korbit by mentioning @korbit-ai.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@korbit-ai Go with your change doesn't make sense. It returns this issue

Property 'helpText' does not exist on type '{ label: string; helpText: string; placeholder: string; } | { label: string; placeholder: string; className: string; } | { label: string; placeholder: string; className: string; }'.
  Property 'helpText' does not exist on type '{ label: string; placeholder: string; className: string; }'.

Copy link

Choose a reason for hiding this comment

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

Thanks for your feedback. It seems like 'helpText' does not exist for all the field types in the FIELD_TEXT_MAP. If 'helpText' is not intended for the fields 'warehouse' and 'role', then the current implementation is ok because it will not cause 'helpText' to become undefined. However, if it should exist for each field type, then we may need to adjust the FIELD_TEXT_MAP to include 'helpText' for every field.

superset-frontend/src/components/Select/utils.tsx Outdated Show resolved Hide resolved
@@ -197,7 +197,7 @@ export function fetchObjectsByTagIds(
{
tagIds = [],
types,
}: { tagIds: number[] | undefined; types: string | null },
}: { tagIds: (number | undefined)[] | string; types: string | null },

This comment was marked as resolved.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@korbit-ai The original input would be [tagId?.id] | '' and this will always yield [undefined] or [number]

Copy link

Choose a reason for hiding this comment

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

Hi @hainenber, thanks for your response. I see where you're coming from and appreciate your reasoning. However, to help ensure that our code is clean and minimizes potential confusion, could we perhaps consider using explicit types based on the actual API requirements? For example refactoring our tagIds parameter to be either all numbers or all strings. This would help eliminate any risk of the calling function passing in an invalid value.

Copy link
Member

Choose a reason for hiding this comment

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

@hainenber Do we actually receive an array that might contain undefined values?

Comment on lines 70 to 76
const nativeFilters = Object.keys(filters).reduce(
(acc, key) => {
acc[key] = pick(filters[key], ['chartsInScope']);
return acc;
},
{} as Record<string, Pick<Filter | Divider, 'chartsInScope'>>,
);
Copy link

Choose a reason for hiding this comment

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

Incorrect Type Union in Native Filters Reduction category Functionality

Tell me more
What is the issue?

The type assertion allows 'Divider' type which cannot have 'chartsInScope' property, potentially causing runtime errors.

Why this matters

If a Divider type is encountered during runtime, accessing 'chartsInScope' will fail as this property doesn't exist on Divider objects, leading to potential undefined behavior or crashes.

Suggested change ∙ Feature Preview

Remove the Divider type from the type assertion as it's not applicable for this operation:

const nativeFilters = Object.keys(filters).reduce(
  (acc, key) => {
    acc[key] = pick(filters[key], ['chartsInScope']);
    return acc;
  },
  {} as Record<string, Pick<Filter, 'chartsInScope'>>,
);

💡 Does this comment miss the mark? Tell us why and Korbit will adapt to your team’s feedback.
💬 Chat with Korbit by mentioning @korbit-ai.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@korbit-ai 72th line has this type for the assigned value: Pick<Filter | Divider, "chartsInScope">. Removing Filter doesn't really make sense for the inferred type.

Copy link

Choose a reason for hiding this comment

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

Hi @hainenber, thank you for your reply. You're correct that the assigned value has the type Pick<Filter | Divider, 'chartsInScope'>. I see the potential for misinterpretation, as the Filter objects surely have the 'chartsInScope' field but the Divider objects do not. For the sake of clarity and to prevent any runtime issues, would it be possible to add some error handling or validation to ensure that the Divider type is not being used in a context where 'chartsInScope' is accessed? This would make the code more resilient to errors caused by type mismatches.

superset-frontend/src/dataMask/reducer.ts Outdated Show resolved Hide resolved
@michael-s-molina
Copy link
Member

Hi @hainenber. Thank you for the amazing PR ❤️

npm run type completes successfully but npm run lint gives the following warning:

WARNING: You are currently running a version of TypeScript which is 
not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <5.2.0

YOUR TYPESCRIPT VERSION: 5.7.3

Can you bump @typescript-eslint/typescript-estree given that newer versions support Typescript 5.7.3?

…s.ts from Michael's suggestion

Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
@hainenber
Copy link
Contributor Author

hainenber commented Jan 28, 2025

Can you bump @typescript-eslint/typescript-estree given that newer versions support Typescript 5.7.3?

I tried out npm upgrade @typescript-eslint/typescript-estree but looks like we'll need to upgrade 3 more major versions, from v5 to v8 to get the latest Typescript support.

I'll see if it's feasible within this PR.

@michael-s-molina
Copy link
Member

michael-s-molina commented Jan 28, 2025

I'll see if it's feasible within this PR.

If this is not feasible, an alternative would be to use a Typescript version <5.2.0 such as 5.1.6.

@hainenber
Copy link
Contributor Author

I tried a quick attempt at @typescript-eslint v6 upgrade but the ESLint config doesn't work at all so yeah, 5.1.6 it is :D

Beside, the PR is pretty full so the less mental burden for reviewers, the better :D

…ted Typescript version

Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
@hainenber
Copy link
Contributor Author

There seems to be a hanging E2E test process at the moment :D

Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
superset-frontend/src/dataMask/reducer.ts Outdated Show resolved Hide resolved
@@ -197,7 +197,7 @@ export function fetchObjectsByTagIds(
{
tagIds = [],
types,
}: { tagIds: number[] | undefined; types: string | null },
}: { tagIds: (number | undefined)[] | string; types: string | null },
Copy link
Member

Choose a reason for hiding this comment

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

@hainenber Do we actually receive an array that might contain undefined values?

Signed-off-by: hainenber <dotronghai96@gmail.com>
Signed-off-by: hainenber <dotronghai96@gmail.com>
…Ids` function

Signed-off-by: hainenber <dotronghai96@gmail.com>
@hainenber
Copy link
Contributor Author

@hainenber Do we actually receive an array that might contain undefined values?

Yes, previously in the codebase, there is this reference. I've changed it so as there will be empty string in place of undefined Tag object :D

Copy link
Member

@michael-s-molina michael-s-molina left a comment

Choose a reason for hiding this comment

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

Amazing work @hainenber! Thanks for improving the codebase and addressing the comments.

@michael-s-molina michael-s-molina merged commit 19e8a70 into apache:master Jan 29, 2025
48 checks passed
@kgabryje
Copy link
Member

I think this PR broke filter indicators.

Before:

image

After:

image

@michael-s-molina
Copy link
Member

@hainenber @kgabryje Can we try to fix it forward?

chart?.queriesResponse?.rejected_filters !==
prevChart?.queriesResponse?.rejected_filters ||
chart?.queriesResponse?.applied_filters !==
prevChart?.queriesResponse?.applied_filters ||
Copy link
Member

Choose a reason for hiding this comment

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

Confirmed that the filter's badge disappeared due to this change - queriesResponse is an array so we need that [0]. Fix in progress

Copy link
Member

Choose a reason for hiding this comment

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

Thank you!

@hainenber
Copy link
Contributor Author

Yikes, this one slipped off my radar. Thanks @kgabryje for doing the fix forward!

@kgabryje
Copy link
Member

No problem @hainenber!
Fix is here #32025

tmsjordan pushed a commit to tmsdevelopment/superset that referenced this pull request Feb 1, 2025
Signed-off-by: hainenber <dotronghai96@gmail.com>
Co-authored-by: Michael S. Molina <70410625+michael-s-molina@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change:frontend Requires changing the frontend dependencies:npm frontend:refactor Related to refactoring the frontend packages plugins size/XXL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants