You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an umbrella issue that centralizes and lists all the potential improvements that we can consider in MUI X v8. The potential improvements being listed here require breaking changes. We do intend to ship v8 in about 9 months. We plan, as much as possible, to release the next major features in minor versions without breaking changes.
Do we want to keep the TimeClock component as the default UI on mobile or to migrate gradually to DigitalClock?
We decided to use DigitalClock on all DateTimePicker components to more closely align with the idea and approach of DateTimeRangePicker.
Created [DateTimePicker] Use digital clock in all component variants #14974.
Do we want to revive the effort on [pickers] Update date calendar styling #9276?
It is almost directly related to MD3 styling.
We decided to keep it for v9 to align with @mui/material adoption of MD3.
This would entail both styling as well as updating the Header component to the UI of MD3.
Can we change the DOM structure of the DateRangePickersDay to have a single HTML element like for PickersDay?
It is basically the same issue as [pickers] Improve calendars customization #14753.
We can start exploring the feasibility of it.
However, it's not a necessity for v8, we can deliver it under a feature flag if needed, or keep it for v9. StyleOverrides and data state attributes combination was the biggest unclear topic if we go for a semi-base approach of putting the state into data- attributes.
Would be great to know if MUI Material has a vision of how styling + data attributes will combine when they will use @base_ui components under the hood. 🤔
[pickers] Field text selection on mouseDown #10048
It is already the behavior on the accessible DOM structure.
There is no clear rushing factor to implement it on the input behavior.
The same behavior is present on other implementations using input (i.e. Kendo).
Should we make unstableFieldRef stable?
We decided to keep it unstable until we use more composition and see if the existing API is sufficient or maybe even redundant.
This is an umbrella issue that centralizes and lists all the potential improvements that we can consider in MUI X v8. The potential improvements being listed here require breaking changes. We do intend to ship v8 in about 9 months. We plan, as much as possible, to release the next major features in minor versions without breaking changes.
Similar discussion for v7: #7902
Data Grid packages
Breaking changes
rowPostionsDebounceMs
prop #15480GridOverlays
export #15483indeterminateCheckboxAction
prop #14300Topics to clarify
slotProps
overrides? [RFC] Issues withslotProps
overrides #14525Pickers packages
Decided changes
PickersMonth
andPickersYear
component and move their logic insideMonthCalendar
andYearCalendar
#14474@mui/x-license
#14476ownerState
on every slot to only pass a small object with valuable information #14475<input />
version of the fields opt-in #14477AdapterDateFns
intoAdapterDateFnsV2
andAdapterDateFnsV3
intoAdapterDateFns
#14478utils
andvalue
params from translations #14648UseDateFieldComponentProps
and equivalent interfaces #14789TDate
generic withPickerValidDate
in every type / interface #14796PickersDay
componentgridcell
role management #11904Topics to clarify
TimeClock
component as the default UI on mobile or to migrate gradually toDigitalClock
?We decided to use
DigitalClock
on allDateTimePicker
components to more closely align with the idea and approach ofDateTimeRangePicker
.Created [DateTimePicker] Use digital clock in all component variants #14974.
Do we want to revive the effort on [pickers] Update date calendar styling #9276?It is almost directly related to MD3 styling.
We decided to keep it for v9 to align with
@mui/material
adoption of MD3.This would entail both styling as well as updating the Header component to the UI of MD3.
DateRangePickersDay
to have a single HTML element like forPickersDay
?It is basically the same issue as [pickers] Improve calendars customization #14753.
We can start exploring the feasibility of it.
However, it's not a necessity for v8, we can deliver it under a feature flag if needed, or keep it for v9.
StyleOverrides
and data state attributes combination was the biggest unclear topic if we go for a semi-base approach of putting the state intodata-
attributes.Would be great to know if MUI Material has a vision of how styling + data attributes will combine when they will use
@base_ui
components under the hood. 🤔[pickers] Field text selection on mouseDown #10048It is already the behavior on the accessible DOM structure.
There is no clear rushing factor to implement it on the input behavior.
The same behavior is present on other implementations using input (i.e. Kendo).
minutesStep
and unify its behavior withtimeSteps
(to avoid such confusions: [pickers][TimePicker]minutesStep
prop not reflecting in UI intervals #14272)[pickers] Is there a way to control the step size sections other than minutes for the field components #13732
Should we makeunstableFieldRef
stable?We decided to keep it unstable until we use more composition and see if the existing API is sufficient or maybe even redundant.
Charts packages
DefaultXxxx
by the usage of hooks #13819d3-color
by CSS filter #13938Tree View packages
Decided changes
TreeItem
and renameTreeItem2
intoTreeItem
(same foruseTreeItem2
and all related components) #14767TreeView
component in favor ofSimpleTreeView
#14768Topics to clarify
Search keywords:
The text was updated successfully, but these errors were encountered: