Save CCAPI chart controls data to disk upon app initialization

[fungjj92]

It was decided in convo in #288 that pre-fetching and persisting CCAPI responses for scenario, models, and dataset to disk upon app initialization is a good idea for 1) reducing requests, 2) app speed, and 3) solving this UI issue:

Saving to disk will likely be useful elsewhere too.

Potential resources:

• https://stackoverflow.com/questions/35191617/how-to-run-a-service-when-the-app-starts-in-angular-2/35191647
• https://gillespie59.github.io/2016/12/04/angular2-code-before-rendering.html

Connects #288

[rmartz]

Do we feel strongly about the specific part of storing static responses to disk? It seems to me there's two goals in this one issue, and one is a fair bit more involved than the other

• Prevent the user from seeing indicator control elements progressively loading
• Retain non-city-specific indicator configuration to disk to save 3 requests per session

The first one is readily achievable and very high value (I already have it done in a terrible way as a POC), but the second is a fair bit more complicated, may require changes to the CCCP, and introduces the pain of cache invalidation. I'm not sure if coupling the two goals together is a good idea given the disparate complexity, and especially with so little time to deal any potential fallout afterwards.

[rmartz]

I think accomplishing the two goals will need to be done separately in order to bypass the problem of first-use loading. If we cache to disk but don't otherwise address progressive loading, the static data will still be lazily loaded the first time and look janky. To avoid that we need to eager load the configuration, at least for the first time, which is a change we can make on the Temperate side.

The second half, saving static configuration to disk, would be a change from within the DatasetService etc about what service their use to cache their results. There might be a way to inject a faked request from a cached value into the CCCP cache on the Temperate side, but that's a pretty gritty technical interaction that feels extremely fragile to me and starts to break down the idea of having CCCP separated in its own package. So we'd need to make that change on the CCCP side.

I have some code to eager load the static configuration, which I think is a necessary step regardless to avoid any first-load jankyness. Doing caching to disk I suspect cannot be done well from within Temperate, so may require a distinct change within the CCCP.

[CloudNiner]

Sorry about the delay, that makes sense though. Eager loading to prime the existing in memory cache seems sufficient for now.

[rmartz]

Opened azavea/climate-change-components#42 about the caching to disk portion, #1093 has been merged and deployed to staging so I'm going to close this, we'll likely want to open a new issue to update our components version once that part is complete.