[docs] Create a recipe of a read-only textfield field

[zgheibali]

Steps to reproduce

Im trying to hide the placeholder when the user clicks on the date range picker input

I'm trying:

      <LocalizationProvider dateAdapter={AdapterLuxon}>
        <DateRangePicker
          value={[values.startDate, values.endDate]}
          onChange={handleChange}
          localeText={{ start: "Start Date", end: "Finish Date" }}
          slotProps={{
            textField: {
              placeholder: "",
            },
          }}
        />
      </LocalizationProvider>

however, for some reason this doesn't work. any suggestion?

Current behavior

In case I add an empty placeholder (or an actual value), the placeholder flickers/changes quickly to the new value and then displays back the date format (e.g. DD/MMM/YYYY)

Expected behavior

I would like to hide the date format (e.g. DD/MMM/YYYY or whatever) from the placeholder and show an empty input if possible

Context

No response

Your environment

npx @mui/envinfo

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

Search keywords: DateRangePicker
Order ID: 69994

[zgheibali]

I just added the Order ID above

[LukasTy]

Hello @zgheibali,
could you please explain in more detail the result you are looking for?
Also, having a live reproduction would help a lot - could you create a StackBlitz or CodeSandbox demo? 🤔
The main thing to focus on is the package version you are using. 😉

As for the placeholder itself, please check #11802 and confirm if we are talking about the same problem.
In which case, the only thing we can suggest, if you strictly need the behavior you are asking for, is to replace the field slot with a simple TextField (it would be a solution between using with button and other examples with custom inputs) and lose all the smart Field components behavior.

P.S. If you are binding value like this in your application, please consider changing it to avoid unnecessary re-renders. Currently, whenever your root component would re-run - it would force a re-render of DateRangePicker because your bound value does not have a stable ref that would persist through renders.

[zgheibali]

Hello Lukas,

Thank you for getting back!

Here's a sandbox where I reproduced the issue: https://codesandbox.io/p/sandbox/dry-https-737fgn

To clarify my issue: when the user clicks on the input field, the format "MM/DD/YYYY" shows up instead of an empty string (or "Start Date" placeholder) and when the user selects his date.. this format disappears.

What is expected: I want to hide the format "MM/DD/YYYY" completely, and based on the comments that I read in the issue section, I believe the "placeholder" param is expected to do that, no?

I tried it and it's not working for some reason. I also don't want to go with a custom text field from scratch as I would lose all the functionality in this case.

any suggestion?

[flaviendelangle]

Hi,

Our field component allow editing through the keyboard arrows and single section selection like the browser built-in component.
When you are focusing the field, it's not exactly a placeholder that is being passed to the input, it's a value which contains the placeholder of each section (MM, DD etc...)

If you render an empty input when focusing, then you can't navigate between the sections when the value is empty or press "ArrowDown" / "ArrowUp" etc... to change its value.
It's another approach, that is of course totally valid, but I don't think you can have both the editing behavior we provide and nothing rendered when focusing.

That's why @LukasTy proposed to render a custom field, that would indeed not have our editing behavior but would fit this requirement.
Is the fact that we render something when focusing blocking you for some use-case or is it more a question of personal preference?

[flaviendelangle]

@LukasTy I'm wondering if a good recipe on how to build a custom field with a mask approach (like on v5) would make sense.
I'm still strongly convinced that our new editing is far better than the v5 one, but we got several feedbacks of people wanting to be closer from a classic input behavior, and with v7 we are shifting even more from it.
We have all the tools needed to create such a recipe AFAIK, we just need to take the time to do it.

WDYT?

[zgheibali]

@flaviendelangle much appreciated for the feedback

So in case I got this correctly, the current date format is injected as the value to the input field to support the feature of changing the input via UP/DOWN/RIGHT/LEFT keys, right?

Now if I pass the placeholder it won't work due to the support of the feature above, right?

Regarding the custom field approach: do you have any working custom field code sample for the date range picker that I can start with and build on that? That would be GREAT!

Thanks again!

[LukasTy]

I'm wondering if a good recipe on how to build a custom field with a mask approach (like on v5) would make sense.
[...]
WDYT?

I completely agree, this is probably at least the 3rd time we are getting this question. 🙈
We could do it in two ways:

1. Explain this behavior and the reason, why the fields behave like this in the docs more clearly
2. Add an example using a mask and a more regular "placeholder" (naturally stressing the worse a11y and UX for editing) 👌

So in case I got this correctly, the current date format is injected as the value to the input field to support the feature of changing the input via UP/DOWN/RIGHT/LEFT keys, right?

Yes, take a look at how the native date input behaves. The field component introduced in v6 closely resembles that behavior.

Now if I pass the placeholder it won't work due to the support of the feature above, right?

Yes, that behavior depends on changing the value in the input, so, if you would check the DOM, when the input is focused, what you are actually calling a placeholder is indeed a value instead. 😉

Regarding the custom field approach: do you have any working custom field code sample for the date range picker that I can start with and build on that? That would be GREAT!

I'm not aware of such an example. We'd need to build it.
Creating a simple example with bare TextField is pretty easy, but if we want to "mimic" the v5/mask behavior, then that's a bit more elaborate effort/example. 🙈

[flaviendelangle]

The closest we got is this example where we replace the input with an Autocomplete.

But adding a masked-based example would but a good way to cover all the custom input-based examples because people could see which props to forward to the input.

[zgheibali]

I worked on this a bit, and here's what I came up with: https://codesandbox.io/p/sandbox/dry-https-737fgn

Do you think all is good? or am I missing something? any feedback is appreciated

Also, I'm not exactly sure about the "masked" feature that you are talking about. I would just like a date range picker with toolbars that popups when the user clicks on the input. is the "masked" feature something that I might have to worry about?

[LukasTy]

@zgheibali That is a bit "hacky", but a working solution. 👌
I've made some small adjustments (mostly reducing the hardcoding) to your example.
Ideally, the solution would be to provide a field slot, thus, avoiding the need for extra overhead that useDateField brings, but in its current form, that is not trivial to do. 🙈

[LukasTy]

I've moved the issue to grooming in order to discuss the best approach and what actual changes do we need on our end. 😉

[LukasTy]

We will firstly solve #13515, which will solve the pain points for introducing a completely custom behavior for field slot and unblock the introduction of a slot customization example we discussed here.

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

Note

@zgheibali How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.