Reorganize In-App Dashboard & Use New Energy Footprint Calculations #1176
+1,696
−2,041
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
Move the components used by a 'row' of cards to a subdirectory of 'metrics' Create new components for each section which groups the cards into a Carousel
Renamed "Summary" section to "Travel" section; this will show 'distance', 'duration', and 'count'
Update types to include 'footprint' as a metric, and revise the sections ('footprint', 'movement', 'surveys', 'travel')
- update color palette to align with Material Design 3 (which is what React Native Paper is based on) - update NavBar component; pass props through to the underlying Appbar.Header, allowing flexibility of elevated = true or false
includes a fix for 'validateDOMNesting' error message
Moved to a more general location since this can be used in many parts of the UI
height = 40 & adjust padding/margins to match standard Material UI button use lighter grey on DateSelect, show on one line and use month + day (e.g. "Sep 9") instead of MM/DD/YYYY
Speeds up development; does not affect production
We had used <Modal> here (while still in the process of migrating from Angular) to ensure the snackbar shows above the rest of the content. This prevented interacting with other content until the snackbar (and its modal) were dismissed. Per RN Paper docs, Snackbars are intended to work with Portals. https://callstack.github.io/react-native-paper/docs/components/Snackbar/ We can do this now that we have a PaperProvider at the App level (index.js)
Bars on a chart get shown with transparency if they begin with this. In a previous version, it was dashed lines, but it's no longer apt to call it dash_key.
This mostly just matters for: 1) testing with historical data, or 2) people whose pipeline is stuck, which indicates a deeper problem. But it will prevent any scenarios where several weeks/months get loaded in all at once. To aid with scenario (1), we can add a button to the TimelineScrollList: if there is no travel in the past week and the pipeline end is not in the last week, this gives us a shortcut to the last processed week
both Label and Dashboard tabs use date & time formatting functions using ISO strings, including with/without weekday, and with/without year, and "humanized" duration strings Makes generic versions of these and puts them in js/util.ts DateSelect will use this as well; as a result it will shift from using a numerical, with year (e.g. "9/17/2024") representation, to an abbreviated string form (e.g. "Sep 17") This is 1) more friendly / less initimidating, 2) allows the datepicker text to be one line, which reduces clutter
If there is an long stretch of time with no data, this implementation will not work; it should keep inserting empty weeks until there are no more days
Categorizing this as "Movement" instead of "Active Travel" Also updating to determine the list of "active modes" from the presence of "met" in the rich modes. Before, this was a config option or defaulted to only "walk" and "bike" (now it will include "ebike" if "ebike" has non-zero "mets", or any other modes with non-zero "mets") -update styles on the cards
When the user first goes to the Dashboard in an app session, we want to show them at least 2 weeks so they can compare the previous week to the past week. But after that we should allow them to select any range. So we can add an 'isInitialized' bool state to mark this, and only do this ">= 14 days" check on the initialization Also add a 'refresh' function which not only refreshes the timeline but also resets 'isInitialized' (along with 'aggMetricsIsLoading')
and fix them since they were flipped ('low' should come first)
e-mission-common 0.6.1 comes with expanded metrics (support for 'footprint', which needs label_options passed from MetricsTab.tsx). Update types: new LabelOptions spec, explicit type for RichMode, add 'footprint' to metricsTypes, add "MetricEntry" type which is like DayOfMetricData but not necessarily for 1 day (it could be aggregated across an entire week, for example) Add "goals" to appconfig.metrics.phone_dashboard_ui.footprint_options
Also fixes translation issue: instead of checking for hardcoded value "Unlabeled" (which probably did not work in other languages) check if the label starts with whatever the "unlabeled" string is for the current language
Shows barchart of average daily footprint for the user, grouped by weeks, colored based on goals ("meter" of green -> red)
Includes checkboxes to break down by a grouping field (mode_confirm, purpose_confirm, etc)
If mode_confirm, then base mode colors are used instead of the 'meter'
Works for either 'carbon' (with kg_co2) or 'energy' (with kwh)
new functions in metricsHelper
- aggMetricEntries combines/ merges array of MetricEntry (used by WeeklyFootprintCard to aggregate multiple days into a week)
- sumMetricEntry adds up all values within a day
- sumMetricEntries does both
The type definitions may look complex here, but all they really do is allow the return type to depend on the 'metricName'. For example, if metricName is 'duration', then the return type is just a number. But if metricName is 'footprint', it is an object containing 'kwh' and 'kg_co2'
This way we don't have to write separate functions for every metric
use the new components, SummaryCard and WeeklyFootprintCard, on the Footprint section. Each of these work for both carbon and energy, so we don't need the 'energy' components, nor the old CarbonFootprintCard and CarbonTextCard A few things of note in FootprintSection: cumulativeFootprintSum sums the footprint metric (which includes both carbon and energy) across all days. This gets fed into SummaryCard Goals are read from the appconfig. Because they are internationalized, though, the labels have to looked up by lang. If a footnote is configured, it is added and a reference to it is appended to the label. The goals are passed to SummaryCard and WeeklyFootprintCard A dynamic footnotes mechanism via `addFootnote`. Instead of including the footnote numbers, (e.g. ¹ ²) directly in the strings, we can round them up for the whole section, keeping track of their numbers, and show them all at the bottom. This allows footnotes to be dynamically shown. If one configuration doesn't use "goals", then that footnote won't show. The "unlabeled" footnote will then become ¹, avoiding any weird scenarios where ¹ is not present and it skips straight to ² We can expand on this later if we want to be more detailed about footnotes, references, data sources
used by WeeklyFootprintCard
instead of setting dateRange only once pipelineRange is set, we can set dateRange upfront and just not do anything with it until pipelineRange has been set This saves us from constantly checking dateRange != null anywhere it is used downstream
It needs to be MultilabelKey by default, otherwise we have to specify this everywhere
Unifies the styling of all metrics cards Adjusts navbar and refresh button on label screen so the label screen and metrics screen navbars match each other
Where base modes were previously a property of the label options, and had a separate set of properties, we now have rich modes that inherit from base modes and may include other properties. This means for the numerous places in the UI where we use mode colors, we should always check the rich mode via get_rich_mode / get_rich_mode_for_value. Also we can tighten down typings a bit more. "text" does not exist in label options or in rich modes. It had been added in while label options are being read and the translations are parsed Instead of that let's just have a function that does this (labelKeyToText). We need to check for translations in 1) the label options being used; and 2) the default label options. if nothing, then convert it to readable (convert underscores to spaces & capitalize) We'll also have a function that does the opposite. Updated some typings: LabelOptions type should not accept a parameter. Also should mark REPLACED_MODE as optional UserInputData should not have "name". This only exists on EnketoUserInputData; it represents the name of the survey
not just the last 14 days
give default argument to MetricEntry and DayOfMetricData so we don't have to specify every time Only ['count', 'distance', 'duration'] are used on the TravelSection; add type TravelMetricName to reflect this I have not added unit utils for 'footprint' yet; but currently it is only used for ['count', 'distance', 'duration'] anyway
There are some places where we want an instance of colors accessible from outside a component, ie. not via useAppTheme
Makes this implementation match what the existing tests are expecting Updates comment since it was out of date
gives a "You vs. Group" comparison for average daily carbon and energy
we do not need to lookup the label by language beacuse getFootprintGoals already handles this
This is necessary to be able to appropriately divide aggregate metrics back to per-user scale for "You vs. Group" comparison
customFootprint not needed anymore; replaced by emcommon footprint calculations aka CHEER 'mets' are not currently in use, but the data in 'metDataset.ts' is included in the base modes in emcommon, so we do have this available to add back in the future
confirmHelper 'json/label-options.json.sample' does not exist anymore so let's just test the default, if we passed a blank config diaryHelper Most of the functions that were tested here don't exist anymore and the tests can be removed. In fact, getDetectedModes is the only one left. However there are functions that didn't have tests, add those footprintHelper All of these functions were removed and there is only one new one, getFootprintGoals metricsHelper The date format changed from numerical month/day to abbreviated month/day imperialConfig Extract the imperialConfig generation to a separate function so it can be accessed outside the hook. Simpler and makes it easier to test. Also let's test both metric and imperial, not just metric
…into energy-dashboard-2024
if acc is not defined or is a number (as with distance,duration,count), do not add nUsers
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.