[pickers] Week no longer respect date-fns weekStartsOn option

[evan-buss]

Steps to reproduce

After upgrading my dependencies, the calendar popup no longer adjusts the week start based on date-fns configuration.

Link to live example: (required)

v6.16.0

• Stackblitz
  

v6.19.6

• Stackblitz
  

Current behavior

No response

Expected behavior

No response

Context

import { LocalizationProvider, DatePicker } from '@mui/x-date-pickers';
import { Typography } from '@mui/material';
import { AdapterDateFns } from '@mui/x-date-pickers/AdapterDateFns';
import { setDefaultOptions } from 'date-fns';
import './App.css';

setDefaultOptions({ weekStartsOn: 1 });

function App() {
  return (
    <>
      <LocalizationProvider dateAdapter={AdapterDateFns}>
        <Typography align="left" variant="body2">
          v6.19.6
        </Typography>
        <DatePicker />
      </LocalizationProvider>
    </>
  );
}

export default App;

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: week start, monday

Search keywords:

[fahdmk]

I think this is a question of prefrences here is someone who went through a lot of trouble to change the starting day to sunday before the update #7670

[flaviendelangle]

I think this is a question of prefrences here is someone who went through a lot of trouble to change the starting day to sunday before the update #7670

The components should follow the locale
This issue you linked is for someone using the en-US locale, which should start on Sunday.
But if someone explicitly set the start of the week the Monday on date-fns, it should work.

I'll have a look

[flaviendelangle]

This regression was kind of introduced in v6.19.0 by #11462
In date-fns, it looks like the locale takes prevalence over the setDefaultOptions({ weekStartsOn: 1 }); config when using startOfWeek
Before, we were not setting a default locale so when using the pickers without any explicit locale you did not have the bug, but it was probably already here with custome locales.

The solution is probably to pass the weekStartsOn explicitely to startOfWeek and endOfWeek

  public startOfWeek = (value: Date) => {
    return startOfWeek(value, {
      locale: this.locale,
      weekStartsOn: (getDefaultOptions() as any).weekStartsOn,
    });
  };

But this seems to not be compatible with SSR because (in NextJS at least), date-fns getDefaultOptions() method does not return the options you set on the server, resulting in an hydration error 😬

cc @LukasTy

[flaviendelangle]

@evan-buss, changing the value inside the locale works:

const customLocale = {
    ...enUS,
    options: { ...enUS.options, weekStartsOn: 1 as const }
}

<LocalizationProvider dateAdapter={AdapterDateFns} adapterLocale={customLocale}>
  {children}
</LocalizationProvider>

I'm not sure we will be able to properly support setDefaultOptions because of the SSR problem stated above.
We are going to take a deeper look and update the doc example if needed 👍

[LukasTy]

As Flavien has mentioned, there does not seem to be a better approach than just going with what date-fns recommends.
date-fns uses the defaultOptions only when no locale is provided.
Going with a custom solution of only updating the startOfWeek and endOfWeek seems a bit flaky. 🙈

Looks like updating the recommendation is our best course of action. 👌

[github-actions]

⚠️ This issue has been closed.
If you have a similar problem, please open a new issue and provide details about your specific problem.
If you can provide additional information related to this topic that could help future readers, please feel free to leave a comment.

How did we do @evan-buss?
Your experience with our support team matters to us. If you have a moment, please share your thoughts through our brief survey.