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

Some noImplicitAny TS fixes #2385

Merged
merged 2 commits into from
Dec 17, 2021
Merged

Some noImplicitAny TS fixes #2385

merged 2 commits into from
Dec 17, 2021

Conversation

Pike
Copy link
Collaborator

@Pike Pike commented Dec 12, 2021

This is mostly about fixing selectors to work on the RootState.

This reduces the TS errors for --noImplicitAny, but increases --strictNullChecks. The culprit there is getSelectedEntity, which used to be any and is Entity | undefined now.

I wonder what state we're in when that's undefined.

I also made things just undefined instead of null | undefined

params: NavigationParams,
): Entity | null | undefined {
): Entity | undefined {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I wonder what kinda state we're in if this doesn't have an Entity?

There's a bunch of code in the frontend that assumes this exists.

Copy link
Member

@eemeli eemeli Dec 15, 2021

Choose a reason for hiding this comment

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

A very bad state. I think it's unreachable unless the state or the store get horribly corrupted somehow.

Really this might be taken as a sign that we should deeply refactor the state handling to reflect this. Not sure if it's worth the trouble, though.

@Pike Pike marked this pull request as ready for review December 12, 2021 21:39
frontend/src/core/editor/selectors.ts Outdated Show resolved Hide resolved
>,
history: ReturnType<typeof historySelector>,
entity: ReturnType<typeof entities.selectors.getSelectedEntity>,
) {
Copy link
Member

Choose a reason for hiding this comment

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

Is the return type intentionally dropped here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, TS is good about deducing it. And leaving out null and undefined should help when we transition to strictNull

Co-authored-by: Eemeli Aro <eemeli@gmail.com>
@mathjazz mathjazz merged commit 80b7dcb into mozilla:master Dec 17, 2021
@Pike Pike deleted the some-ts-any branch December 18, 2021 07:47
@Pike Pike added the typescript PRs related to the conversion to TypeScript label Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
typescript PRs related to the conversion to TypeScript
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants