@uppy/status-bar: remove throttled component

[arturi]

Fixes #4339

[Murderlon]

I think this would also fix it and follows the React paradigm better:

function ThrottledProgressDetails () {
  return throttle(ProgressDetails, 500, {
    leading: true,
    trailing: true,
  })
}

But even better would be to not throttle a component, but the state the triggers a re-render.

[mifi]

I don’t think throttling an actual React component is kosher. Usually one would rather throttle some events or throttle state updates. What’s the reason for needing to throttle the component? Is the rendering happening inside of it very slow? I think if the problem is that state updates too frequently, then we should instead throttle the setState calls where they happen.

[arturi]

I think the progress details numbers were jumping around too frequently. This was added some years ago, I don't remember for sure. We can try and remove and see how it goes again.

I agree with the idea of throttling the data / setState, but it might be harder because only a certain part of the progress was throttled, while percentage wasn't. Will take a look.

[mifi]

alright! alternatively we could use or make some kind of useThrottle hook, that can allow us to throttle multiple variables too

[Murderlon]

Still went with the simple approach. Tried everything but didn't work, new hooks, changing the throttle interval in Uppy core, moving components around. This is simple and fixes the problem.

[aduh95]

Maybe add a comment explaining why we are wrapping it in a function, or a later refactor may revert it by accident.

[mifi]

I think we should just remove the throttling. I tested without throttling for s3, multipart, xhr and tus, and it doesn't seem to be jumping frequently. Since we have forgotten why we throttled, it seems like an unnecessary optimisation. And throttling react component renders like this doesn't sound safe to do.

[aduh95]

I think we should just remove the throttling. I tested without throttling for s3, multipart, xhr and tus, and it doesn't seem to be jumping frequently. Since we have forgotten why we throttled, it seems like an unnecessary optimisation. And throttling react component renders like this doesn't sound safe to do.

Could it be that you are using a machine in the 99-percentile in terms of power and you would have seen different results if you tested using a below average smartphone?

[mifi]

Could it be that you are using a machine in the 99-percentile in terms of power and you would have seen different results if you tested using a below average smartphone?

the numbers update every 1 second so i don't see how it could be a problem with a slower computer. and the throttle is even set to 0.5 sec

[arturi]

something failing on e2e?

[Murderlon]

Unrelated and caused by d1697b0

[aduh95]

Unrelated and caused by d1697b0

We should have waited for the fix to land first, otherwise we can get back to the state where the CI is failing and we don't know why.