LocalizationProvider

[dmtrKovalenko]

Closes #1504

User facing changes

LocalizationProvider

Rename and changes in API for MuiPickersUtilsProvider. It is renamed to LocalizationProvider. In future this provider may be moved to the @material-ui/core

- <MuiPickersUtilsProvider utils={DateFnsUtils} />
+ <LocalizationProvider dateAdapter={DateFnsUtils}  />

Also, LocalizationProvider now accepts special dateFormats prop that allows globally override formats used for displaying dates

const formats = {
  normalDate: 'd MMM yyy',
  keyboardDate: 'd MMM yyy',
};

<LocalizationProvider
  dateAdapter={DateFnsAdapter}
  locale={frLocale}
  dateFormats={formats}
/>

Also, libInstance from now renamed to dateLibInstance which is a more meaningful name in case of reusable LocalizationProvider

dateAdapter prop

There is a new prop dateAdapter in each component which allows passing configured date adapter object without context

const memoizedDateAdapter = useMemo(() => {
    return new DateFnsAdapter({ locale });
  }, [locale]);

<DatePicker
  value={selectedDate}
  onChange={date => handleDateChange(date)}
  dateAdapter={staticDateAdapter}
/>;

[vercel]

This pull request is being automatically deployed with ZEIT Now (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/mui-org/material-ui-pickers/pl8kib09x
✅ Preview: https://material-ui-pickers-git-feature-localizationprovider.mui-org.now.sh

[cypress]

---

Test summary

61 • 0 • 0 • 0

---

Run details

Project	material-ui-pickers
Status	Passed
Commit	e0a3f71
Started	Mar 1, 2020 5:17 PM
Ended	Mar 1, 2020 5:18 PM
Duration	00:59 💡
OS	Linux Debian - 9.11
Browser	Chrome 78

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[codecov]

Codecov Report

Merging #1537 into next will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             next    #1537   +/-   ##
=======================================
  Coverage   91.83%   91.83%           
=======================================
  Files          63       63           
  Lines        1763     1763           
  Branches      320      304   -16     
=======================================
  Hits         1619     1619           
  Misses        109      109           
  Partials       35       35

Impacted Files	Coverage Δ
lib/src/_shared/KeyboardDateInput.tsx	88.57% <ø> (ø)	⬆️

---

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 b2c19b0...e0a3f71. Read the comment docs.

[oliviertassinari]

Should the import come from?

Suggested change

	import DateFns from '@date-io/date-fns';
	import dateFns from '@material-ui/pickers/adapter/date-fns';

But I wonder about keeping the file system flat?

Suggested change

	import DateFns from '@date-io/date-fns';
	import dateFnsAdapter from '@material-ui/pickers/dateFnsAdapter';

[dmtrKovalenko]

I think the main point is to make library names the same (date-fns) and not dateFnsAdapter? What do you think about it, IMHO it will be more clear for users

[oliviertassinari]

I don't have a clear idea of the best approach. There is a tradeoff between the consitency of the filenames and the npm name of the dependencies. Both seem OK.

[oliviertassinari]

What do you think of using React.useState?

Suggested change

	import React, { useState } from 'react';
	import React from 'react';

[dmtrKovalenko]

It is even more invalid, somewhere I thought that this kind of import will be deprecated. We are primarily using import * as React, but in examples using this notation.
I have no preference and can change

[oliviertassinari]

There is a related thread on this topic at mui/material-ui#19802.
What approach have you seen the more frequently used by TypeScript users on one side? And by JavaScript users on the other?

There are no clear guidelines by React on the matter, but I could find these two examples:

• https://reactjs.org/docs/hooks-intro.html
• https://www.typescriptlang.org/docs/handbook/react-&-webpack.html

[dmtrKovalenko]

For typescript codebase, it is much easier to use import * as React because a lot of internal types are also exported, like React.ReactNode, React.HtmlProps and so on.

My own notice: It is easier to visual recognize default react hooks like useEffect or useState when they are used like React.useEffect, thus all custom hooks are easily distinguishable

[dmtrKovalenko]

Should we update Readme? Because it will affect new v3.x, because next is our default branch.

[oliviertassinari]

Maybe the Readme should point to the documentation websit and be kept generic?