- replaced normal details view of 'My distance' with chart
- next steps
    - create button to switch between chart and details view in 'my distance' card
    - Figure out why all data is showing up unlabled
    - Allow the axis to switch easily
        - right now, setting isHorizontal doesn't completely switch data, only thedirection of the bars
        - would be nice to flip data axis and bar axis simultaneously

- one (MetricDetails) is going to be a copy of the original metric details view
- the next (MetricsCard) is going to be a container to have both the BarChart component, and the MetricDetails component
    - Will be a react component, rather than function, and will hold onto the state of whether or not the barchart or metricdetails will be showing

- next steps
    - add a button to switch between the two views

- allows the card to keep track of whether or not it has a BarChart or MetricDetails child component
- next step
    - Add button

- next step
    - format and style button

- button allows switching between the BarChart and the MetricDetails card
- button icon switches depending on the card represented

- removed children property from card
- removed leftover code from copying from BarChart.tsx to MetricsCard and MetricDetails
- Removed unecessary import statements

-- also switched main-metrics html so that only the MetricsCard element is held in the ion-slide element, without any extra divs or headers

…sion/e-mission-phone into dashboard-rewrite

The new dashboard will have the MetricsTab component as its entry point - main-metrics.html will no longer be rendered

Replacing main-metrics, this component represents the entire Dashboard tab and will get metrics data from the server, store it as state, and pass it down to child components like MetricsCard.

There is also a date picker at the top (TODO) and a refresh button.

The logic for fetching metrics has been modernized into modern JS (async/await) and uses Luxon instead of Moment. I tested to make sure the timestamps of the resulting queries are the same using Luxon as they were with Moment.

This typing is based on the data we receive from the server.
For each metric, we receive an array containing "days" of metric data. Each day has a few props (ts, fmt_time, nUsers, local_dt) plus any number of properties with the `label_` prefix that represent the measurment for a particular label.

Having this be type-safe from the start should make it much easier to realized the desired visualizations!

MetricsCard will now accept 'metricDataDays' as a prop and derive the chart data from this.
We can employ `useMemo` for this so that iff metricDataDays changes, chartData updates.

Prior to this, MetricsCard had an IconButton on the right side allowing users toggle between 'details' and 'graph' view.
To be clearer to the user, I have changed this to a SegmentedButtons. This way, users see both their options side by side and can select the desired one.

A few colors were added in appTheme.ts - surfaceDisabled and onSurfaceDisabled.
These are colors that already exist in the React Native Paper default theme, but we are overriding for our own purposes.
In the SegmentedButtons on MetricsCard, the surfaceDisabled color is used for the button that is not checked

With the new MetricsTab, MetricsDetails will receive 'metricDataDays', sum up the totals for each label, and display these in a 2-column.
The display is the same as the old dashboard, but now the logic to sum up the values is here in this component instead of jumbled in with everything else.

MetricsDateSelect will allow users to select a date range. It appears as a NavBarButton, like the label screen date picker, and also uses a DatePickerModal.
However, this one works differently because users can select a range of days instead of just one.

The selected range is stored in LabelTab as `dateRange` - once this range is loaded, all the displayed metrics will update to reflect the new data.
`dateRange` is an array of two Luxon DateTime objects, which works well to bridge between the JS Date objects (used by RN Paper Dates) and Unix timestamps (used by e-mission-server / for any network calls)

The chart does not need so much padding - we want to be able to show as much detail as we can.
MetricDetails should show with 2 columns, but could use some padding in between.

So let's remove all the padding from the card content since its children will have padding anyway.

The "active minutes" should display the cumulative duration for modes that are considered "active" - currenty this is just 'walk' and 'bike'; I am not sure if anything else will count.
This should include a graph later on, but right now it just lists out the minutes for each mode.

The same type will be used for both user metrics and aggregate metrics, so its naming should be more generic.

This adds type definitions for the React hooks and makes some of the annoying typing errors go away.
I don't know why the React package doesn't have types built-in, but this is how you get them.

It's not really necessary for MetricDetails to be its own component - it is actually simpler to just include these few lines of code in MetricsCard.
Then MetricsCard will handle the memoized computation either way, whether it's `chartData` or `metricSumValues` that is needed (depending on whether 'graph' or 'details' is active)

It was incorporated into MetricsCard and is no longer a standalone component

…sion/e-mission-phone into dashboard-rewrite

It is useful to have the format function (which handles rounding to 2 or 3 sig figs) generic enough to work for any unit.
We can also have it use Intl.NumberFormat to work better with other languages (other languages might use commas and periods differently, or have a different decimal marking altogether)

Using a prop passed to MetricsCard called unitFormatFn, we will format the raw numerical values as human-readable strings in the correct unit of measurement.

Added a second pair of SegmentedButtons to allow toggling between 'user' and 'aggregate' metrics.
So now there are two toggles - instead of repeating all that SegmentedButtons code, I extracted it out into a new ToggleSwitch component, which is a generic wrapper around SegmentedButtons for our particular uses.

Each MetricsCard now accepts both userMetricsDays and aggMetricsDays, instead of just one metricDataDays, and it determines which to use based on the value of the toggleswitch - "populationMode"

viewMode was not in the dependency array, so if it was changed in isolation, metricSumValues would not recompute.

I noticed that when the content was tall enough to allow vertical scrolling, you could not scroll to see the bottom even though the content was in a ScrollView.
Upon inspection, the new Dashboard tab was growing infinitely tall, past the bottom of its Angular parent container.

We've had this happen a couple times before when embedding React components into Angular views.

The way we get around this is with a CSS class called 'fill-container'. I modified it slightly to only affect the *direct* child, not all grand- and great-grand-children. Without this modification, the entire tab would be hidden from view.

We have been showing time-based data on the BarChart, where one of the axes (depending if horizontal or vertical) has values as Unix timestamps.

We'd like this component to also work with categorical data, so we will have a boolean prop `timeAxis` to say whether it should be timestamps (true) or categories (false).

Also, the way BarChart receives input data has been changed. ChartJS accepts input, categorized by 'datasets' which have their own label. For us, this correlates to the different labeled modes.

However, the metrics we get from the server lend themselves better to a 'flattened' structure - we receive an array of days, and what labels were for that day; we don't receive an array of labels with what their value was on each day.

So we would have to flip this data around in each place that the BarChart was used. Instead, it's simpler for BarChart to accept a flattened structure - and we can do the flipping here in BarChart before the flipped data is fed into ChartJS.

And to better keep track of all this, let's introduce typings for the input, flat 'records' and for the resulting, flipped 'chartData'.

BarChart was reworked to accept a 'flat' array of records instead of a deep structure tailored for ChartJS.
The flattened structure is more congruent with the userMetricsDays / aggMetricsDays that comes upstream from LabelTab.
The BarChart component now handles tailoring this to a format that ChartJS can work with.

-move some common styles to a common location MetricsTab
-shorten height of MetricsCard title bar
-remove top/bottom borders of ToggleSwitch buttons

Considering the most recent two weeks for which days of metric data have been loaded, we calculate the total weekly time spend a) walking and b) biking. We store these totals as weeklyActiveMinutesRecords to be included in a vertical, categorical BarChart.

`flex: 1` was added to the BarChart component (if it is vertical), as well as to the card content. This allows the "Active Minutes" chart to grow as tall as the Card and display the bar chart more effectively.

Also add i18n key for "active minutes"

Bulk of the work here is data formatting to use FootprintHelper, done in two main steps

parseDataFromMetrics takes in the userData of one metric at a time from the server and gathers "mode bins" resulting in an array of objects with "key"(mode) and "values"(array of arrays of values, one array per day with times and value of the mode)

THEN generateSummaryFromData takes each of those binned modes, and aggregates down to a single value - either with sum or avg

The 'distance' mode from this summary is digestible to FootprintHelper, used so far to get low and high estimates

lots TODO - splitting into "current" and "prev" weeks, agg metrics, goals ...

BarCharts will be stacked by default for:
-Active minutes ('walk' and 'bike' minutes stacked together)
-MetricsCard charts - but they will be toggleable by a checkbox, so they can be either unstacked/stacked. Stacked looks a lot cleaner, especially with a lot of modes showing, so it will be the default.

In BarChart.tsx, getChartHeight was modified to account for stacked charts - if labels are stacked on the chart, then the chart height doesn't depend on how many labels are showing and we can just use a constant for the height of each bar (36 was a comfy height).

To make it clearer what data is being used to calculate week-wise metrics, "Past week" and "Previous week" should be annotated with the specific dates they encompass.
For this to not clutter the chart, I wanted these to be on a newline, like this:

Past Week
8/21-8/27

ChartJS doesn't support this by itself - `\n` is just rendered as a space - but we can remedy this by adding a callback function under ChartJS options > 'scales' > 'ticks' that splits a label into an array if it has `\n`.

the dashboard works with the label keys "e.g. 'walk', 'drove_alone'. To show these as readable text we can repurpose a function from `confirmHelper.ts` which is used for "other" text.
Let's rename it to be more generic, make it work with more than just 1 underscore, and export it so we can use it on the dashboard too,

`unitFormatFn` should be used on the chart so the values appear in the listed unit and not the raw value.
(e.g., '3 miles' instead of '4828 meters')

The horizontal ScrollView requires a few tricks to get the scrolling to snap correctly while managing the card widths and margins.
Let's extract this logic to a reusable "Carousel" component so we can use it multiple times without MetricsTab getting too cluttered.

card now retrieves and stores user data for past and previous weeks, worst-case emissions, and US goals

used filterToRecentWeeks from metricsHelper.ts to separate user data into the last two weeks, and display data for both if the range is 2 weeks or more

worst-case carbon is calculated with a method in FootPrintHelper called on the total distance for the most recent week

if there is a previous week, we use current and previous to calculate a percent change over the two and display it to the user

using bar chart, we are able to present the carbon metrics to the user visually. There will be two colors on the graph, one for "certain" and one for "uncertain" to display the range -- graph in rough draft stage currently, want to add baselines and adjust colors

also tweaked the labeling in BarChart in response to an error thrown when there were more x axis than labels -- this change shows correct x axis labels for both cards that rely on these categories

"Average speed" needs to be handled differently because it is not mathematically correct to average it across days without considering differences in distance and duration between those days.
(described in e-mission/e-mission-docs#961)

We can comment this out; maybe revisit later

Let's change the initial loaded range so that we get 2 full weeks of data. This is so that the weekwise comparisons can show "past week" and "previous week" - if we only had 13 days we could only show "past week" and not the full "previous week"

using the lineAnnotations attribute, adding the goal lines to the Carbon data graph

Right component of the CarbonFootprintCard is now an indication of change over past two weeks

The element is only visible when there is a change to show, is red when carbon increasing and yellow when carbon decreasing, and shows ranges when labeling leaves doubt

The new ChangeIndicator component accepts an array of numbers of length 1 or 2 to display change as a single value or a range. This new component separates the logic and styling, and could be used on another card later if desired.

change the boolean for isHorizonal to true and flip x and y values (since x and y are flipped to turn horizontal)

remove unused code, unused imports, and development log statements

also refactored userCarbonRecords useMemo to handle the graph records, old UserCarbon was used for text-based display in initial draft

incorporating a patch from @JGreenlee to allow the labels to split lines when the graph is horizontal

made updates to en.json and CarbonCard to enable i18n translation of labels, titles, etc.

"(kg Co2)" is now the only hard-coded string here

using aggMetrics and the same data processing functions, group average is shown alongside user specific metrics

We might need to consider hiding this if it is too far out (I'm thinking of nrel-commute, for example, where about 5/6 trips are unlabeled)

remove accidental import, and adjust to better match the wireframe

in ChangeIndicator, discovered an error where negative values showed prefixed by -- instead of -

added abs calls to prevent this double negative

When we override the callback in any manner, we're responsible for all formatting of the ticks https://www.chartjs.org/docs/latest/axes/labelling.html

overriding to "undefined" meant that the default tick formatter was never called, and the time ticks were unformatted

By bumping the timeAxis switch up a level, we prevent overriding the default time ticks, and the dates are shown in an intuitive way

when switching from 2+ weeks to a date range < 2 weeks, we should take the change indicator off the card, we accomplish this by setting the emissionsChange to "{}"

in the case of NaN, we want to display the change as infinite, since it's a result of dividing by a 0 value for the previous week

This range is no longer needed, as we can use the {low, high} object without converting it

show group bar with user metrics for "seeing how you stack up"

add goal lines in yellow and red to show that "less is more"

This is basically just a wrapper around SegmentedButtons; let's type it as such and still allow any other SegmentedButtonsprops to be passed through

So it may be used on other screens in the future

Now this is a perfect wrapper around SegmentedButton, accepting exactly the same props and just applying a different default style.
This should aid in reusing this component on other screens.

These functions were committed by accident in c468478 and did not belong there

refactoring this and putting it in a Carousel in preparation of creating a new card component to place in the carousel

The LineChart has only a few differences from BarChart - there is no 'stacked' or 'annotations', but we must consider a few new properties: 'borderColor' 'borderWidth' and 'tension' for the lines between points

This component has a line chart showing (up to) the last 14 days, with active minutes for each day on the Y axis. There are separate lines for bike and walk.

-adds the CDC recommended 150 minutes, positioned centered
-the 'overall' totals should show if activeModesDurations exists and has a length greater than 0 - if we don't include the '>' operator the expression may evaluate as the number 0, which would be rendered as text

It's actually important to push records for every day on this chart, even if the values are undefined or otherwise falsy.
For example, most people don't bike every day - so we need to show gaps in the line graph on the days they don't, and the only way to do that is to pass falsy values through.

…d-rewrite

Needed to resolve merge conflicts in order to preserve local changes

added parameter to BarChart to allow for a "meter" chart -- with a green/yellow/red scale changing at specified "middle" and "high" values, dashed lines for uncertainty appear when labeled "dash_key"

changed "goal" for "guideline" to further emphasize NOT exceeding it, shortened for better formatting

added keys for "labeled" and "unlabeled", replaced what was hard-coded as "certain" and "uncertain"

when the dashed guidelines are the same colors as the bars - and they cross- the line disappears

By darkening the lines slightly, we preserve their visibility when the two objects cross

e-mission/e-mission-docs#961 (comment)

this import should have been a part of 71adf57

adding an explanatory footnote to the Carbon card, so users know what the goals mean

e-mission/e-mission-docs#961 (comment)

With all the charting features we've added, this file has gotten fairly long and messy.
To keep things tidy, let's extract some of these functions to a separate file called charting.ts.

In the process, let's ensure the BarChart is properly typed. Upon reading documentation, I found out that we can type the chart data by using ChartData<'bar', {Z}> where Z is the values that each data point has (in our case, x and y values, which can be number | string)

This makes all the type definitions line up - before this, we had a lot of different type warnings because TypeScript didn't understand our data structure.

for accessibility purposes, the information should be available in ways other than the graph, so that it is easier for a screen reader to successfully navigate the page

e-mission/e-mission-docs#961 (comment) -> implementing this suggestion

isolate the text to a dedicated card, and place the "meter" card and "text" card in a carousel, now we have three rows, each a carousel.

also isolated data management functions shared across the two cards into `metricsHelper.ts`

The two cards keeps information easily accessible to those using a screen reader, while maintaining focus on the "meter" card and not cluttering the screen

Update the color scheme to correspond to the colors used on the label screen to represent each mode

Otherwise duplicated colors are handled by darkening or lightening the base color for subsequent modes of the same "base"

storing the modeColors with useMemo means they will only update when chartDatasets change (preventing bog-down issue encountered in development)

this was committed by accident as an artifact of some earlier experimentation

- use 'forEach' as it is a bit more concise than the traditional for loop
- instead of formatLabelForSearch, we can borrow a function from confirmHelper that does exactly this and was just sitting around waiting to be used. Let's also ensure this function follows the same process as its opponent function `labelKeyToReadable`, but in reverse, and unify their naming scheme and add descriptions. This function can also be used in MultilabelButtonGroup because we do the same formatting there.

chartData itself depends on modeColors, and nothing else uses modeColors. modeColors and chartData both depend on the same thing (chartDatasets) and should update whenever it does.
So we can just have modeColors be computed inside of the body of chartData.

And to ensure we have labelOptions defined, we'll add that to the dependency array, returning blank data if it isn't defined

The gap between cards should not be bigger than the gap before the first card / after the last card. To get this effect, the first and last card need full size margins, while the inner margins can be half that.
Overall this gives us slimmer margins that are uniform.

in an effort to give some more space to the chart itself
e-mission/e-mission-docs#961 (comment)

it seems more comprehensible when organized this way

React warns us about the missing 'key' prop if we don't put a key whenever we iterate and repeat components, so a `key` was added to this View.

The way the brackets were arranged on line 89 was actually causing a single space " " to be rendered, which React was also warning us about in the console.

This description is basically a footnote - why not formally represent it as such?
We'll use small text and a superscript ¹ to mark the footnote.

We want these cards as wide as possible to show all the info we have without it seeming cramped.
But we cannot go too wide or the bleeding edge won't show. Here is a good balance.

mistakenly, the previous and past weeks were showing the same "certain" value

I noticed that even with a 43% change the bars looked the same, and was able to catch and fix my mistake

We want our code used for charting to be fairly generic and not specific to any particular use case. So instead of handling the mode labels and their base modes in charting.ts, we should refactor this so the logic is encapsulated in the appropriate areas of the codebase.

To accomplish this, BarChart can accept a function `getColorForLabel` that it will use on each of the labels it finds in `records`. This way, BarChart and charting.ts don't have to specificially deal with the lookup of the base mode colors.

The logic that *does* get included in the charting code, because it is needed for visually distinguishing labels on the charts, is the de-duplication function. I refactored this to be more generic as well - not based on fixed 'stops' of darkening/lightening. Instead, it finds how many duplicates there are and evenly distributes them in lightness. So if there are 2, one will be lightened and the other darkened. With an odd number, the middle will stay the same. And the more duplicates, the closer in shade they will be.
Darkening was toned down by a scale of .5 because it has a more drastic effect than lightening.

The modeColors themselves were also slightly adjusted in diaryHelper.ts - notably, the difference in hue between 'pink' and 'red' was widened. Besides this, everything was made very slightly lighter and the oklch comments were updated to reflect in-gamut saturation values.

…m/e-mission/e-mission-phone into dashboard-rewrite

Instead of repeating a bunch of code between BarChart and LineChart, let's refactor this into a common Chart component that works with a type of either 'bar' or 'line'.

Then BarChart and LineCharts will simply be composed of a Chart with the appropriate type specified.
Any logic specific to BarCharts or LineCharts can be put in the respective files.

Currently, LineChart has no specific logic and the only thing BarCharts have specifically is the 'meter' prop.

Now that we refactored, the line chart can accept getColorForLabel in the same way that bar charts do.

for react routing, we need to convert this page and the sync settings page

maintain access for now by routing to a React page with angular routing

using AlertBars for the error messages

first draft: scrolling the FlashList is broken and the data doesn't load unless you manually tap refresh