-
Notifications
You must be signed in to change notification settings - Fork 317
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
move default retry logic on to defaultOptions #637
Conversation
On a second though, this approach is not ideal because it would be a breaking change for some users. When you are providing a custom After thinking more about this, I am unsure if we can use |
I'm not sure what you mean. If we provide a default value and a user also provides a value the default will be overwritten, then the exact same thing that happens today does. Today if a user provides a function then the default functionality does not run. That hasn't changed. Also, I didn't expose |
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.
You are right, this PR does not present a breaking change for users.
I have two comments on the code. Could you also please have a look at the lint issues in upload.js
: https://github.com/tus/tus-js-client/actions/runs/6573176315/job/17950213388?pr=637#step:7:43
Alright, I've pushed changes and left a comment about the type change. When I run lint on my machine it gives a bunch of errors and warnings about line endings and files I didn't change, but I think the lint error is fixed. |
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.
Thank you for your help!
closes #636
it was suggested that the default value of
onShouldRetry
should be set toshouldRetry
but that won't work becauseshouldRetry
callsonShouldRetry
, so I opted to move the code at the bottom ofshouldRetry
into a function declared ondefaultOptions
. I wasn't quite sure what we wanted to do if a user explicitly setonShouldRetry
to null. Currently the default logic would still be used, so that's what I preserved here, though it does look a bit awkward.I wasn't able to run tests or execute a build locally. I kept getting a build error about a subdirectory or file already existing.