-
Notifications
You must be signed in to change notification settings - Fork 377
Add additional type-casts for React nodes #7402
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
Conversation
|
Preview: https://patternfly-react-pr-7402.surge.sh A11y report: https://patternfly-react-pr-7402-a11y.surge.sh |
|
@nicolethoen @tlabaj could this get reviewed and merged? I'd like to rebase the React 18 PR on top. |
| const movedOptions = | ||
| prevState.availableTreeFilteredOptions || | ||
| flattenTreeWithFolders(prevState.availableOptions as DualListSelectorTreeItemData[]); | ||
| flattenTreeWithFolders((prevState.availableOptions as unknown) as DualListSelectorTreeItemData[]); |
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.
Curious. Why unknown here and not 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.
The unknown keyword still allows a stricter subset of type checking, whereas any disables all checks. But in this case I used unknown as it was the recommendation by the compiler.
nicolethoen
left a comment
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 im realizing that you're needing to cast these list as unknown since the chosenOptions and availableOptions props are both typed as React.ReactNode[] | DualListSelectorTreeItemData[].
It seems as though, since the tree feature was added later, we could tighten the typing of these various lists of options used throughout the component to avoid using the 'unknown' casting. Unless casting to unknown was something recommended as part of the migration to react 18 and is a fine solution. WDYT?
|
@nicolethoen dual list selector is still Beta so we can make improvements to API that are "breaking" I do not know if that is blocker for this PR though. we could open a follow up issue to address that. @jonkoops any thought on this? |
|
Sorry for the late response, I have been focused on some other projects so I haven't had the time to get back to this.
Yes, I think it makes total sense to re-work these types. Ideally there would never be any
Agreed, let's open up an issue for this. Especially if this is still a 'beta' feature I think it makes sense to stabilize this before making it set in stone. I think we can merge this as-is so I can continue creating new PRs to help with the React 18 migration. WDYT @nicolethoen @tlabaj? |
tlabaj
left a comment
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
|
I opened this follow up issue for the dual list selector |
Since React 18 has stricter types than before some type-casts need to be added and expanded in order for the code to compile successfully.
Needed to land #7142