Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
@uppy/status-bar: refactor to typescript #4839
@uppy/status-bar: refactor to typescript #4839
Changes from all commits
4d7893d
8561abd
45fac24
c890cf6
86cb254
76d29f2
de3dd27
4aa00e8
4cb1caf
4854bba
271f3da
e3a778d
7ac4402
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 222 in packages/@uppy/status-bar/src/Components.tsx
GitHub Actions / Lint JavaScript/TypeScript
Check warning on line 254 in packages/@uppy/status-bar/src/Components.tsx
GitHub Actions / Lint JavaScript/TypeScript
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.
to avoid NaN
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.
This PR is about adding types, we should refrain from making any change that would affect the JS output
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.
But I thought that rule was to not introduce breaking changes. In this case, does it matter that the JS output changes? I think we’re missing on the critical benefit of a TS refactor, which is improving our code to be more stable along the way, like in this case.
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.
Shouldn't we fix be fixing bugs that we discover while refactoring to TS, even though it changes the JS output? At the very least we should add a TODO to fix such discovered bugs in the future
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.
IMO non-null assertions are an implicit TODO. We should go through them and remove them on the 4.x branch
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.
I think non-null assertions are fine to use in some cases, when the alternative is to check for nullish and throw an error (like
maybeNull!.something
). But in this case, the bug will render NaN, and in this case the correct solution is probably not to throw an error, but instead render something like0
.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.
uppy/packages/@uppy/status-bar/src/Components.tsx
Line 260 in 4854bba
As you can see, if the value is indeterminate, that
roundedValue
will not be read.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.
then it's better to put the round after the determinate check, then we don't need the non-null assertion, because typescript already knows that it's not nullish:
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.
I agree, but I'd prefer to not introduce runtime changes when we can avoid it. My wish is we'd be able to get rid of all non-null assertions on the 4.x branch, and turn the linter warning to an error.