mui
[pickers] Add support for single input fields in range pickers
Closes #7606
I'll try to extract some part from it to ease the reviewing
Doc for the controlled selectedSections (only usage in the doc of the new fieldRef)
Doc for the single input DateRangePicker
Not sure where we should document it.
We will soon have a "use a custom field" page with the examples from #7806, but putting the example above in the DateRangePicker page feels very natural until we have other range pickers.
Netlify deploy preview
Netlify deploy preview: https://deploy-preview-7927--material-ui-x.netlify.app/
Updated pages
- docs/data/date-pickers/custom-field/custom-field.md
- docs/data/date-pickers/date-range-picker/date-range-picker.md
- docs/data/date-pickers/fields/fields.md
These are the results for the performance tests:
| Test case | Unit | Min | Max | Median | Mean | σ |
|---|---|---|---|---|---|---|
| Filter 100k rows | ms | 670.6 | 1,174.6 | 670.6 | 872.96 | 200.811 |
| Sort 100k rows | ms | 655.9 | 1,187.5 | 1,187.5 | 980.46 | 193.971 |
| Select 100k rows | ms | 277 | 397.8 | 319.1 | 330.72 | 48.504 |
| Deselect 100k rows | ms | 148.1 | 486.4 | 247.6 | 267.9 | 116.656 |
Generated by :no_entry_sign: dangerJS against 7b91450ae586cd502a0cc1f2a1008fe534edd25b
This pull request has conflicts, please resolve those before we can evaluate the pull request.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
Found a possible issue with selected range position controlling.
Thanks for the feedback ! I changed the implementation, it should work now
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
@flaviendelangle I can see that SingleInputDateRangeField has a TextField slot so I assume we will be able to use input adornments to add a calendar icon for example, right?
Sure,
By default we have the same behavior as the range (open on focus)
But we can discuss to switch to the behavior of DatePicker (open on click on the endAdornment).
@joserodolfofreitas what's your opinion on this ?
@flaviendelangle I think the default should work for us as long as clicking anywhere in the textfield, including the endAdornment could open the picker. It's hard to be a 100% sure without consulting with designers and product owners.
I will come back to you on this one.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
I think the example may look better if the field is not too long.
You want to set a smaller custom width to the input ?
How can we configure the fieldSeparator? I tried to use the same slot as on the usual Date Range Picker, but it didn't work.
That's not strictly related to this PR because it's purely a field API, but the separator of the single input range fields is not configurable. It can't be the same slot than the multi input range fields since it's inside the input (you can't render HTML inside an input). We could add a prop to configure this separator if we wanted in the future.
I think another example using the endAdornment will be welcomed by the community.
That's not supported yet. It's the question raised in https://github.com/mui/mui-x/pull/7927#issuecomment-1474164137 What should be our default opening strategy for range pickers with a single input field ? Input adornment or focus ? Not sure we should support both in the 1st version because it would require to add some mechanism to switch between the two, mechanism that we need to imagine to allow the same kind of customization for the other pickers.
I would probably be in favor of keeping the "open on focus" behavior for now because with the input adornment we need to potentially rework the keyboard navigation of range pickers.
You want to set a smaller custom width to the input ?
Yes, the empty space on the right is dead and makes it feel unbalanced.
We could add a prop to configure this separator if we wanted in the future.
That would be great. It was the first thing I tried to do.
That's not supported yet. It's the question raised in https://github.com/mui/mui-x/pull/7927#issuecomment-1474164137
Ah, ok. I thought when you answered "sure", it meant users could already add it.
What should be our default opening strategy for range pickers with a single input field ? Input adornment or focus ?
I think that adding an adornment shouldn't necessarily change the "open on focus" behavior in a "OR" way. I think it's likely that users may only want it as decoration (which is the main role of an adornment); it can also be useful to close the view (and reopen it).
That would be great. It was the first thing I tried to do.
I created an issue (#8369)
I think it's likely that users may only want it as decoration (which is the main role of an adornment); it can also be useful to close the view (and reopen it).
I'm not following you here.
If it's purely decorative (clicking on it does nothing). Then people can already add it themselves. But I fear that it would confuse end users if some end adornment are clickable and others not.
If it has interaction (clicking on it toggles the opening of the view). Then people can add it themselves if they control the opening, but it view will still open on focus and the focus will still remain on the field while editing (no keyboard navigation on the view). I'm not sure that's a good pattern in term of accessibility.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
Yes, the empty space on the right is dead and makes it feel unbalanced.
Done
And demo added with an decorative end adornment
think that these are a few last nitpicks to iron out before merging:
Sorry, you can ignore this one. It's already on "master" and can be solved separately. 👌
