(tracking changes for configurable dashboard) #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Up to now, the dashboard has only been shown for MULTILABEL configurations; on ENKETO configurations it was completely hidden. We are making the dashboard more configurable - e-mission/e-mission-docs#1055. The presence of a new field `metrics`.`phone_dashboard_ui` being defined will cause the dashboard to be shown. If `phone_dashboard_ui` is not defined, it will fall back to the current behavior (which is to only show dashboard for MULTILABEL configurations).
e-mission/e-mission-docs#1055 (comment) *** sections A list of sections to show in the dashboard UI. They will appear in the specified order from top to bottom. Options are footprint, active_travel, summary, engagement, surveys. Whichever sections are omitted will not be shown in the UI. Default: ["footprint", "active_travel", "summary"] ***
If there is no active_travel_options.modes_list, set the default active modes
…enlee/e-mission-phone into configurable-app-dashboard
… configurable-app-dashboard
Leaflet map encounters an error when prerendered, so we need to render the TimelineScrollList component when the active tab is 'label' 'shouldUpdateTimeline' state is used to determine whether to render the TimelineScrollList or not
purpose : prevent too much API call
…enlee/e-mission-phone into configurable-app-dashboard
When I first designed the survey dashboard, it showed the accumulated survey data regardless of the selected date range. However, the updated logic is that the survey metric depends on the date range selected, while the leaderboard metric remains accumulated.
Survey Comparison Card: Data depends on date range. Survey Leaderboard Card: Data is accumulated. To prevent confusion for users, we separate the two cards and inform them that the leaderboard data is accumulated.
Instead of querying by timestamp we can now query by "YYYY-MM-DD" strings. The yyyy_mm_dd endpoint also has a different format for metric_list: instead of just an array of metrics, it is a mapping of "metric names" to "grouping fields" (e-mission/e-mission-server#966 (comment)) We will specify this in the config as "metrics_list". The yyyy_mm_dd endpoint will also ask for app_config, so we will pass that through to `fetchMetricsFromServer` and include it in the `query` (note that `survey_info` is the only field that needs to be included) We will be supporting another metric called "response_count"; added a card to the 'summary' section (if it is configured to show) Updated types in appConfigTypes.ts
Making this more generic because we will now support fields other than the labeled mode (such as labeled purpose, BLE sensed mode, and survey that was prompted)
Instead of specifically listing a MetricsCard for each metric, we can read metricsList and map each key to a MetricsCard.
But the structure for response_count is an object of {responded: number, not_responded: number}, while the other metrics are just numbers.
So we need to adjust change the way days get summed up to account for both.
The 'showsIf' conditions in dfc-fermata currently reference 'confirmedMode'. We want to rename this to 'primary_ble_sensed_mode'. Also see JGreenlee/e-mission-common@0396339
This makes it easier to test aggregate metrics locally
Instead of dummy data, we can now use real values via the "response_count" metric. Since our data is chunked by day and this comparison is across all surveys for all days loaded, we need a function (getResponsePctForDays) to sum up the 'responded' and 'not_responded' and calculate a percentage. This is called on userMetrics for "you" and on aggMetrics for "others". It was easy to swap in the real percentages to the existing doughnut charts and they look great!
Instead of dummy data, we can now use real values via the "response_count" metric. For each survey, we sum up the 'responded' and 'not responded' across all loaded days. Then include the totals in the chart records
Since we have implemented the real metrics for the "surveys" section of the dashboard, we do not need the dummy metrics anymore. Commented out the "engagement" section (leaderboard); it will be done in the next step.
I noticed a discrepancy – the server request has "metric_list" but the config and dashboard UI uses "metrics_list" / "metricsList". Unifying to "metric_list" for consistency throughout the project.
This version has the updated metrics structure which all the recent commits use
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.