User-defined date range

[anp]

Needs:

1. Additional summary endpoint with dates
2. UI elements for date pickers
3. Figure out how Ember should handle (different view? live reloading? I have no idea)

[anp]

@chriskrycho to follow up on #52:

The plan is roughly: provide a start/end pair of datepickers which allow the user to change the date range for which metrics are displayed on any particular tab. The API endpoints support query strings like ?start=20160407&end=20160607 to return more or less data than the default 30 days, so that part's done. The backend for this work is done with a macro, since of the summary endpoints take a since, until pair of parameters: https://github.com/dikaiosune/rust-dashboard/blob/master/src/server/handlers.rs#L15

Ideally:

The start/end pickers should be first populated with the first & last date returned by the API server, so that one doesn't need to specify the exact ranges to get a useful response. For the first load of the view, I'm picturing something like AJAX -> Response -> Ember Data -> Populate dates in template, and then having a handler which registers Datepicker change event -> modify start/end date of model -> fetch new code through adapter -> re-render template. Is that in line with what Ember offers?

Various API responses can be cached based on dates, so that in a bright future we might only fetch those ranges which haven't already been stored. I'm thinking it'd be nice to have a caching schema that would allow a user to jump around multiple date ranges, only hitting the server some of the time. Only problem is that (AFAICT) the ember-data store relies on integer IDs, which aren't super amenable to date range keys.

[chriskrycho]

Basic flow/template/etc. bits: I think the overall idea totally makes sense.

For the first load of the view, I'm picturing something like AJAX -> Response -> Ember Data -> Populate dates in template, and then having a handler which registers Datepicker change event -> modify start/end date of model -> fetch new code through adapter -> re-render template. Is that in line with what Ember offers?

That basic flow should work well, yep. I'll refactor accordingly when I come back to this, either this afternoon or tomorrow. One note: in Ember, the normal workflow will be sending an action from the date-picker to the controller and updating things accordingly, rather than dealing with event listeners. (Actions are just curried method calls which Ember handles all the dispatch for itself, so usually you don't have to worry about managing event bubbling, etc.)

We'll have something roughly like this, then—

Template:

{{date-picker value=model.start onSelect=(action 'chooseDate')}}

Controller:

export default Ember.Controller.extend({
    actions: {
        // a good picker will pass the selected date to the action; otherwise
        // we'd need to write the event handling within the action ourselves
        chooseDate(/* args? */) {
            // handle the date
        }
    }
});

For convenience, we might want to grab something more consistent with modern Ember than pikaday unless you're strongly committed to it; I'll look around at other options this morning.

---

API stuff: you're right about the default for storing things on the data store, but gladly you can override what the primary key is for a given item, so if using a date makes sense, we can do that.

The overall API should be fine as is, though; any tweaks we need to make should be pretty straightforward in the same place: a serializer. That's another reason to switch to using an Ember.Model instead of doing the AJAX manually.

[anp]

Sounds great. I'm generally indifferent to what datepicker is used -- there just happened to be some promising google results for "skeleton css datepicker" and "ember cli datepicker" 😄.

I like the idea of customizing the keys, but on further reflection I wonder if perhaps it's overkill to try to figure out where the gaps are on the front-end and then only call for those summaries. Not because it's not nifty, but I'm thinking that the network round-trip overhead is a large cause of latency for me, not the size of the data transfer.

[anp]

Boilerplate: I'm going to refocus this project on rfcbot, since that's the primary usage rusty-dash.com is seeing.