Replace moment specifier with format/parse functions

[TrySound]

This PR will remove moment dependency in favour of parse and format helpers which can be handled with library chosen in a team.

[codecov]

Codecov Report

Merging #518 into master will increase coverage by 0.51%.
The diff coverage is 100%.

@@           Coverage Diff            @@
##           master   #518      +/-   ##
========================================
+ Coverage   99.48%   100%   +0.51%     
========================================
  Files          15     15              
  Lines         581    608      +27     
  Branches      123    129       +6     
========================================
+ Hits          578    608      +30     
+ Misses          3      0       -3

Impacted Files	Coverage Δ
src/addons/MomentLocaleUtils.js	100% <100%> (ø)	⬆️
src/DayPickerInput.js	100% <100%> (+2.25%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5954f41...02f6bc9. Read the comment docs.

[gpbl]

Thanks for this PR!

I was thinking to provide a default format, e.g. format could return the day as YYYY-MM-DD, and parse would convert it to a Date object. String(new Date()) is a bit too generic as it returns also the time.

I was reasoning about writing a small utility that could recognize D, DD, M, MM, YY and YYYY as format strings, so that format would accept also strings like DD-MM-YY and parse would convert them accordingly. The idea is to cover the most common cases without writing too much code.

[gpbl]

@TrySound also I believe parse and format should receive the locale as second argument, which may come from the dayPickerProps.

const parse = (string, locale) => { return 'parsedDate' };
const format = (date, locale) => { return 'string' };

<DayPickerInput 
  dayPickerProps={{ locale: 'ru' }} 
  format={format} 
  parse={parse}
/>

This would help developers to implement their own i18n.

[TrySound]

Maybe better to pass date objects directly and use internal format and parser for simple specifer as defaults. So you don't need to expose these defaults to let users understand date.

[gpbl]

Maybe better to pass date objects directly and use internal format and parser for simple specifer as defaults. So you don't need to expose these defaults to let users understand date.

Not sure I follow – what do you mean?

[TrySound]

<DateInput value={new Date(1992, 12, 20)} onChange={d => console.log(d.toISOString())} />
This will allow to work with date directly without parsing received one.

[gpbl]

OK, this is another change we can consider, and it makes sense – as it is somewhat related to #508 ("Move input related props to inputProps").

Until now, the value prop means "value" as in input fields, i.e. is expected to be a string. Once we close #508, we can do this. However, I'd open another PR for this change – on the master branch where moment is still a required dependency – to be sure we update the tests just for that change.

[gpbl]

I also think we should open a v7 branch and merge these PR there.

There are still some fixes to do on v6 that I would like to publish before other breaking changes.

[PeterKottas]

Hi guys, where do we stand with this? Do we have a date in mind for v7? I rly think getting rid of this moment dep is high priority

[gpbl]

@PeterKottas me too :) The problem is that there's a pending minor release, I'm working on it right now.

I'd like to release this minor version where you can optionally opt out from moment. I.e., it defaults to moment, but if you specify format and parse attribute, it will not. I'm not sure if it is possible, however.

[PeterKottas]

Oh that sounds cool. You should definitely be able to do that. Just require the module, then check if it's define before you use it and fallback to some detetime format. I think you already have logic for that there. It would however need to remain a peer dependency which scares some people away. But it it's only for now, I'd go for it.