refactor(cli/unstable): print progress bar when value and max are changed

[timreichen]

This PR decodes buffers in tests and compares them to strings for easier comprehension.
It adds getters and setters for value and max which call #print() when the value changes and also recalculates unit and rate when max changes.

[codecov]

Codecov Report

Attention: Patch coverage is 96.55172% with 1 line in your changes missing coverage. Please review.

Project coverage is 94.71%. Comparing base (e10c71a) to head (8b4110f).

Files with missing lines	Patch %	Lines
cli/unstable_progress_bar.ts	96.55%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6664   +/-   ##
=======================================
  Coverage   94.71%   94.71%           
=======================================
  Files         567      567           
  Lines       46778    46799   +21     
  Branches     6582     6585    +3     
=======================================
+ Hits        44305    44326   +21     
  Misses       2431     2431           
  Partials       42       42           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[BlackAsLight]

I don't see the point of calling the #print function every time the values are updated. If value is updated a lot then that can lead to a lot of unnecessary prints.

[timreichen]

I don't see the point of calling the #print function every time the values are updated. If value is updated a lot then that can lead to a lot of unnecessary prints.

I wouldn't say these prints are unnecessary. If there is a lot of progress, I think it is beneficial to see that reflected on the progress bar more than every second, no?

[BlackAsLight]

I don't see the point of calling the #print function every time the values are updated. If value is updated a lot then that can lead to a lot of unnecessary prints.

I wouldn't say these prints are unnecessary. If there is a lot of progress, I think it is beneficial to see that reflected on the progress bar more than every second, no?

No. I very likely could be updating value 100x a second. That is a lot of wasted prints.

[timreichen]

I don't see the point of calling the #print function every time the values are updated. If value is updated a lot then that can lead to a lot of unnecessary prints.

I wouldn't say these prints are unnecessary. If there is a lot of progress, I think it is beneficial to see that reflected on the progress bar more than every second, no?

No. I very likely could be updating value 100x a second. That is a lot of wasted prints.

I updated the PR so it checks every 100ms for updates. That way there is a new print every 100ms at most and only on changes while maintaining a mandatory print every second.

[kt3k]

How about using throttle from @std/async/unstable-throttle to throttle the too many calls? That has no delay when the print call is not throttled.

constructor(...) {
  ...
  this.#throttledPrint = throttle(this.#print, 100)
}

set value(...) {
  ...
  this.#throttledPrint()
}

[kt3k]

No. I very likely could be updating value 100x a second. That is a lot of wasted prints.

What would be the maximum reasonable number of re-rendering in a second?

[BlackAsLight]

No. I very likely could be updating value 100x a second. That is a lot of wasted prints.

What would be the maximum reasonable number of re-rendering in a second?

Idk, but I think it would be better to leave that up to the user to decide. Looking at the docs, I could have sworn there was an option for them to control the frequency of the updates, but that doesn't seem to be the case.

I think an inconsistent update interval though could give the effect that the program is having lag spikes and any "delta" values that are introduced or manually calculated via the formatter option can have big jumps up and down.

[timreichen]

No. I very likely could be updating value 100x a second. That is a lot of wasted prints.

What would be the maximum reasonable number of re-rendering in a second?

Idk, but I think it would be better to leave that up to the user to decide. Looking at the docs, I could have sworn there was an option for them to control the frequency of the updates, but that doesn't seem to be the case.

I think an inconsistent update interval though could give the effect that the program is having lag spikes and any "delta" values that are introduced or manually calculated via the formatter option can have big jumps up and down.

No. I very likely could be updating value 100x a second. That is a lot of wasted prints.

What would be the maximum reasonable number of re-rendering in a second?

Idk, but I think it would be better to leave that up to the user to decide. Looking at the docs, I could have sworn there was an option for them to control the frequency of the updates, but that doesn't seem to be the case.

I think an inconsistent update interval though could give the effect that the program is having lag spikes and any "delta" values that are introduced or manually calculated via the formatter option can have big jumps up and down.

Not sure if we should advertise to use the fmt function for such cases in the first place. It is meant to format the output after all, not explicitly for delta calculations.

[kt3k]

I think an inconsistent update interval though could give the effect that the program is having lag spikes and any "delta" values that are introduced or manually calculated via the formatter option can have big jumps up and down.

I see the point, but it feels weird that we can't update frequently to keep the delta calculation correct..

How about splitting the printing of progress bar and the calculation of delta of the value?

[timreichen]

I think an inconsistent update interval though could give the effect that the program is having lag spikes and any "delta" values that are introduced or manually calculated via the formatter option can have big jumps up and down.

I see the point, but it feels weird that we can't update frequently to keep the delta calculation correct..

How about splitting the printing of progress bar and the calculation of delta of the value?

Another option would be to provide delta calculations as properties. cli-progress and progress do this.