Feature proposal - indeterminable progress bar (unknown total) #121
Conversation
|
Happy to review a PR! |
| this.total = options.total; | ||
| this.width = options.width || this.total; | ||
| this.width = options.width || (this.total > 0 ? this.total : Infinity); |
There was a problem hiding this comment.
Not sure if Infinity is a good default here.
There was a problem hiding this comment.
What is the point of this change?
There was a problem hiding this comment.
With my proposal this.total could be non-positive, but we can't use non-positive value as a default for width.
So, we need a sane default value. Infinity here means that progress bar will attempt to use all available space.
|
Attached my PR with proposed implementation and usage example. |
|
Code is out of date. Needs to be updated before considered @lbeschastny |
Changes: * new `.done()` method to complete the progress * new `.updates` counter to track `.render()` calls * support for non-positive `.total` * no more `.tick()` calls after progress bar is complete and terminated
lbeschastny
force-pushed
the
indeterminable-progress
branch
from
decdd0e to
7d35259
Compare
|
@thebigredgeek rebased my branch onto the latest master. |
|
Hi! Thank you for your job! |
|
This is a very helpful feature and wondering if this could actually be made available officially via this package. |
|
Any update on this? Any help required? |
In some situations you may not know the total number of ticks, but want some progress reporting nonetheless.
Right now I have two particular use-cases in mind, but I'm sure there are more:
content-lengthheader.Here is how I solved this problem in my
clj-progressmodule (node-progressport to Clojure):It will be very nice to have something like that in
node-progressas well.If you'll approve my proposal, then I could try to implement it myself based on my previous Clojure implementation, and send you a PR. Though I'm not sure when I'll manage to find some time to do it.