Animate sparklines #795
Animate sparklines #795
Conversation
|
Looking good
|
| this.x.domain([first, last]); | ||
|
|
||
| this.y.domain([ | ||
| this.props.min || d3.min(data, d => d.value), |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
It would be cool to have a better domain for the load averages. (They still "jump around a bit"). But I'm not sure what that would be, some dynamic rolling average perhaps. |
|
As the sparkline updates more frequently than the label the two feel a bit out of sync sometimes. You see a spike whizz by, but the label failed to capture it. It might be a bit annoying to have the number changing too often also though. |
|
We could separate out the logic a little more so that ticking/buffer-merging happened in an Anywho, looks good! |
|
The latest value next to the sparkline was out of sync because it was not rendered by the bit-by-bit fed sparkline. The logic to feed the data has been extracted but this needs to be adapted when #752 is merged, because the number layout changes there. I suggest we wait for that. BONUS: smooth out the y-domain, maybe via an exponentially dampened moving average like load itself. |
* Refactored sparklines to be rendered by react * Correct row key for sparklines * Extracted data feed into animated-sparkline * last value is rendered by sparkline now, because it relies on the last value that it is fed, not the lastest availble value
also added sortBy date after merge in value buffer
davkal
force-pushed
the
638-animate-sparklines
branch
from
29e781f to
0a0179a
Compare
|
Format renderer fixes are included, fixes #902 |
|
Looks good! Minor issues:
|
|
Code looks good. HOC FTW LGTM |
* also increase sparkline feed to 60 secs * and keep historic max
* tried activating it for child tables too, but that became quite CPU intensive, and feed intervals became out of sync (host CPU < container CPU, which is hard to believe)
|
Final comment: the child tables are not fed by the feeder, so the big top metrics seem to change all the time, while the metrics in the tables stay the same til the next details request. This comes with 2 drawbacks: (1) they dont look like they re updating that often. I tried using the feeder there too, but it was quite CPU heavy and they quickly became out of sync. (2) as the big metric is going through the samples it may have a lower value than that of a child metric, which wont add up, e.g. host CPU < container CPU. |
|
LGTMTM |
Fixes #638