Skip to content
This repository has been archived by the owner on Aug 21, 2023. It is now read-only.

Support monthly indicators in line graphs #107

Merged
merged 3 commits into from
Oct 25, 2016

Conversation

fungjj92
Copy link
Contributor

@fungjj92 fungjj92 commented Oct 21, 2016

Overview

Line graphs weren't set up to take monthly indicator data. Now they are!

Demo

screen shot 2016-10-21 at 11 51 05 am

Closes #105

@@ -132,6 +131,12 @@ export class LineGraphComponent {
// Time scales only recognize annual and daily data
var parseTime = D3.timeParse(this.timeFormat);
this.extractedData.forEach(d => d.date = parseTime(d.date));

// Sort data by date ascending
this.extractedData.sort(function(a, b) {return a.date - b.date;});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates a type checking error:

[default] /home/local/AZVA-INT/khoekema/projects/climate/climate-change-lab/src/app/charts/line-graph.component.ts:136:56 
    The left-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

To me it seems like the problem goes back a little ways. I.e.

  • The DataPoint type defines its date attribute as a string here
  • But the LineGraphComponent overwrites it with a javascript Date object here

That seems like a bad situation. If we want dates, we should convert much earlier (e.g. here where the data is initially loaded). That would require moving the config that's used to parse and interpret the date to somewhere where it can be shared, but that might be a good thing anyway. Anything that's using DataPoint values as defined (i.e. treating the dates as strings) would have to be checked/revised to handle Date objects.

If we mostly want to keep the date keys as returned by the API (i.e. 'YYYY', 'YYYY-MM', or 'YYYY-MM-DD' strings) then we should define a separate data type for use inside LineGraphComponent and explicitly convert the data to that format. (Also, setLineScales seems like a weird place to mutate the data in a way that affects all subsequent steps. Doing it in filterData where the extractedData object is created would make more sense to me.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. There isn't a reason to maintain the string format of date that comes from the API. It makes sense to process date in the service while we are chopping up the data.

I could define two types: RawDataPoint and DataPoint. Former, string date; Latter, date date.

@fungjj92 fungjj92 force-pushed the feature/SupportMonthlyIndicators branch from 43a9729 to 64e145d Compare October 25, 2016 15:22
@fungjj92
Copy link
Contributor Author

Updated. I am now processing the strings into dates in chart.service and we still only have 1 type, DataPoint which now expects a Date date not a string date. Should be no more linter errors.

Copy link

@KlaasH KlaasH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. 👍

var parseTime = D3.timeParse(this.timeFormat);
this.extractedData.forEach(d => d.date = parseTime(d.date));
// Sort data by date ascending
this.extractedData.sort(function(a, b) {return +a.date - +b.date;});
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Me: That seems like a kludge, can we do better?
The Google: microsoft/TypeScript#2361 (comment)
Me: 😱

Coercion it is!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol javascript.

@fungjj92 fungjj92 merged commit 4d2f824 into develop Oct 25, 2016
@fungjj92 fungjj92 deleted the feature/SupportMonthlyIndicators branch October 26, 2016 14:43
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants