Improve keyboard navigation for date range selection

[monokrome]

These changes represent an effort to improve the navigation of the date range selection via keyboard. This is primarily modifying the position of the DayPicker so that it is after the currently focused input on the date ranges, and comes with a few small changes to keep reasonable usability for keyboard navigation inside of the DayPicker.

[monokrome]

@majapw Although not ready for review yet, I'm creating this PR as requested so that you can see the current code 😺

[coveralls]

Coverage decreased (-0.2%) to 84.968% when pulling e137cea on tkjr-calendar-tabbing into d572bea on master.

[majapw]

Yay, nice test coverage! I think overall we'd prefer to use the onTab/onShiftTab callbacks in the DayPicker as the solution for this rather than add this blur handler. In addition, I think the props already exist on the DateRangePickerInput(Controller) that let you know where to put the calendar.

[monokrome]

Oops! Need to write test! Will do so tonight :D

[majapw]

I'm a bit confused about the comments about the children prop! Maybe we can talk through it tomorrow.

Other than that, it's looking great!

[majapw]

Hey @monokrome, would be good to get a status update on this tomorrow! I'd like to do a release for @nkinser's change and I'd love to get this in too if it's close.

[monokrome]

Discussed a bit with @majapw, but I want to document why we are using focusoutinstead of tab for anyone else following.

I spent a bit of time trying to find a way to do this with onblur/onfocus/onkeydown, but the event doesn't give us the information that we need. Tabbing out sets document.activeElement to the body element when the next item isn't a form element (possibly in that case as well).

In order to ensure that we are staying safe, I have implemented this using the focusout event on an element ref until facebook/react#6410 is released, at which time we can consider using FocusOut natively. 😺

[majapw]

One major comment (about the children && children line). Everything else looks good!

[majapw]

Any update on this?

[monokrome]

@majapw I think this is ready for review now. All changes mentioned have been made, with the caveat that I switched the naming for the currentDateOffset to renaming the local variable to nextDateOffset to retain dateOffset in state. Happy to change that, but this feels like a smaller change and the name current in state felt a bit redundant 😺

[majapw]

Assuming everything has been smoke-tested thoroughly in storybook, this looks great! I just have one comment where I think this.state.nextDateOffset was accidentally used instead of dateOffset