This appears to be a duplicate of https://github.com/facebook/flow/issues/2715

Is there a way to add anything on the function declaration IwontMutate to make sure the previous error wont show?

Not currently, no.

I think this is just the empty type. (try)

I just fell prey to this :sob:

I feel like it's almost more confusing to provide offset when changes to it are not detected. It sets up the expectation that the user does not have to worry about detecting changes anymore.

It seems like there is not currently a way to specify that the value is indeterminate. DOM's <progress /> and and Android's ProgressBar both support indeterminate modes, can rc-progress?

i wonder if we can match tracking numbers based on the depot code?

hmm, it's weird that DPD doesn't actually send out tracking numbers with check digits. even if you enter a tracking number with a bad check digit in their website, they just ignore it. for other carriers the check digit is always included.

a check digit, in this case, is one of the mechanisms that the tracking_number ruby gem (tracking_number_data is build specifically to be used with the ruby gem tracking_number) uses to match a tracking number to a carrier. this is more reliable than just doing a regex alone, which is more likely to have false-positives.

the important thing about a check digit is that we need to know which digit in the tracking number is the check digit, and how it is calculated, then we can verify it. i did some research into this for DPD a while ago and i found this PDF:

DPD Parcel Label Specification.pdf

take a look at sections 4.1 and 4.2.6.1. they describe the tracking number format and the check digit. i haven't looked too deeply into this, so i'm not sure if all the valid DPD tracking number formats are described here, however.

also the important thing to note here is that scramble does not currently perform any check digit checks. scramble just naively checks the regexes, because scramble is not using the ruby gem and we never bothered to write the corresponding logic in javascript.

the really weird part of this is that skillet does use the ruby gem tracking_number which i'm pretty sure is just a coincidence. skillet uses tracking_number to find carrier info and send it down to scramble as part of the order history data, but then we don't use it. the main reason we don't currently use this is because skillet does not send a tracking URL.

so, in an ideal world, this is how we would move forward:

1. merge this stuff for now as it is, without worrying about the check digit because we're not ready to check it anyway. roll this out for odlo.
2. dig into the DPD tracking number format and implement DPD tracking number support into tracking_number_data, send a PR to jkeen/tracking_number_data.
3. update the skillet gem to use this new version of jkeen/tracking_number / jkeen/tracking_number_data, so that skillet supports DPD tracking numbers.
4. start sending a tracking_url column from skillet to scramble in addition to the tracking number column and the carrier column.
5. modify scramble to use the tracking_url from skillet instead of finding the tracking url on the scramble side.
6. delete all tracking number related code from scramble.

another direction that we should probably consider is using a third-party service for generating tracking URLs. i feel like this is the kind of problem that we will be continually running into, and there must be a good service out there somewhere to do this.