-
Notifications
You must be signed in to change notification settings - Fork 14.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time shift difference #5177
Time shift difference #5177
Conversation
I think this is effectively the same as a superior I know one difference in the backend is that |
Codecov Report
@@ Coverage Diff @@
## master #5177 +/- ##
===========================================
- Coverage 76.78% 61.21% -15.58%
===========================================
Files 44 373 +329
Lines 8944 23709 +14765
Branches 0 2750 +2750
===========================================
+ Hits 6868 14513 +7645
- Misses 2076 9181 +7105
- Partials 0 15 +15
Continue to review full report at Codecov.
|
I'm not familiar with the period ratio, and it doesn't seem to map 1:1 to the comparison types. Should I create a migration script only for those cases that can be mapped?
How I would that with the period ratio? For time shift you would select the last 28 days and then use "1 year" as the time shift. |
…me_shift_difference
@@ -1562,24 +1562,6 @@ export const controls = { | |||
description: t('Compute the contribution to the total'), | |||
}, | |||
|
|||
num_period_compare: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If deprecating num_period_compare
and period_ratio_type
, do we need a db migration for existing charts that have been saved using that feature?
LGTM apart from the db migration needed comment. |
@mistercrunch, I've added a migration script. Here's a dashboard that was saved before the migration: Note that:
After the migration: Now:
|
LGTM |
@betodealmeida this broke my local build, the db migration fails. I think you need to check if granularity is defined. |
Same here |
@@ -68,6 +68,7 @@ | |||
"geojson-extent": "^0.3.2", | |||
"geolib": "^2.0.24", | |||
"immutable": "^3.8.2", | |||
"is-react": "^1.1.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@betodealmeida @mistercrunch was it necessary to add this dependency for functionality that is already provided by React natively?
from the source:
React.isValidElement(typeElement)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI this added react 16 as a direct dependency (not a peer dependency), which means we have 2 versions of react floating around. it'd be great to get rid of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me take a look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in #5478.
* Allow different comparisons when using time shift * Remove test code * Remove lead/trail NaN and improve code * Add headers/subheader * Update yarn * Migration script * Fix migration * Small fixes * Trigger tests * Fix lint * Fix javascript
* Allow different comparisons when using time shift * Remove test code * Remove lead/trail NaN and improve code * Add headers/subheader * Update yarn * Migration script * Fix migration * Small fixes * Trigger tests * Fix lint * Fix javascript (cherry picked from commit 7b4e6c7)
self.to_series( | ||
diff, classed='time-shift-{}'.format(i), title_suffix=label)) | ||
|
||
return sorted(chart_data, key=lambda x: tuple(x['key'])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@betodealmeida we've been seeing issues with the stacked line chart where the lines are not sorted correctly. The stacked chart has sort_series set to true, and that sorting is done before this gets called, so I think this sorting is causing the issue. Is it necessary to sort here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taking a look at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC this is needed in order to color the groups in different timeshifts with the same color (eg, make sure "boys" is red in the main series as well as all offsets).
* Allow different comparisons when using time shift * Remove test code * Remove lead/trail NaN and improve code * Add headers/subheader * Update yarn * Migration script * Fix migration * Small fixes * Trigger tests * Fix lint * Fix javascript
I added a new control to allow comparing comparing the main time series with time shifts. In addition to showing the time shift as individual lines, it's now possible to compute absolute and relative differences.
Current behavior, will be the default option in the selector ("individual lines"):
Absolute difference:
Relative difference, computed as
(main - time_shift) / time_shift
(for a "1 week" shift" this means that100
means the value today is double the value last week, and-50
means that the value today is half of what it was last week):