Open KarineBrandelli opened 4 months ago
Hello @KarineBrandelli Here is an updated CodeSandbox with some comments and working behavior. I've added comments on most props to improve clarity. It looks like everything is working as expected when props are passed in expected locations. Please let me know if there are still any issues. π
Hello @KarineBrandelli Here is an updated CodeSandbox with some comments and working behavior. I've added comments on most props to improve clarity. It looks like everything is working as expected when props are passed in expected locations. Please let me know if there are still any issues. π
Hey @LukasTy! I appreciate you took the time to take a look at this.
But it kinda didn't do what I needed, sorry if I wasn't to clear on my explanation.
When the input it's cleared, I need it to be empty, like if a empty string is passed, but it doesn't accept strings, and should not be rendering the MM/DD/YYYY hh:mm:aa
text on placeholder and neither on the input value when focused.
When the input it's cleared, I need it to be empty, not rendering the
MM/DD/YYYY hh:mm:aa
text.
This is essential for the behavior of the field components.
If you remove the valueβthe field behavior can no longer function.
If you don't need the improved behavior/UX for entering dates and only want to reply on the calendar/view, please consider replacing the field
slot with a more trimmed-down component, which would not have the "smart" behavior, and then consider making the input read-only.
Or maybe your use case can be improved by avoiding an input component altogether? π€
When the input it's cleared, I need it to be empty, not rendering the
MM/DD/YYYY hh:mm:aa
text.This is essential for the behavior of the field components. If you remove the valueβthe field behavior can no longer function. If you don't need the improved behavior/UX for entering dates and only want to reply on the calendar/view, please consider replacing the
field
slot with a more trimmed-down component, which would not have the "smart" behavior, and then consider making the input read-only.Or maybe your use case can be improved by avoiding an input component altogether? π€
Infortunally none of the options (sadly π’).
I'm migrating from @material-ui/pickers
and the old version allowed empty inputs, so my company kinda wants the 'same' UI as before. It need to be an input, that allows to pick from the calendar and also to type it (tricky right? π )
I'm migrating from
@material-ui/pickers
and the old version allowed empty inputs, so my company kinda wants the 'same' UI as before. It need to be an input, that allows to pick from the calendar and also to type it (tricky right? π )
I hope you can prove to your company that moving towards a better UX is the way to go, instead of clinging to old behaviors. π€ π The whole industry (i.e.: Adobe Spectrum DateField) seems to be moving in this direction after the introduction of native date input. Our approach is trying to resemble native date input as closely as possible with deviations where we think that it makes sense. π€
What you are asking seems to be a demo of how to replace the field
slot with a component that would use a masked input just like in v5.
Given our perspective on the masked vs fields approach, we would much prefer to not have such an example to steer users toward a better UX approach.
I'm migrating from
@material-ui/pickers
and the old version allowed empty inputs, so my company kinda wants the 'same' UI as before. It need to be an input, that allows to pick from the calendar and also to type it (tricky right? π )I hope you can prove to your company that moving towards a better UX is the way to go, instead of clinging to old behaviors. π€ π The whole industry (i.e.: Adobe Spectrum DateField) seems to be moving in this direction after the introduction of native date input. Our approach is trying to resemble native date input as closely as possible with deviations where we think that it makes sense. π€
What you are asking seems to be a demo of how to replace the
field
slot with a component that would use a masked input just like in v5. Given our perspective on the masked vs fields approach, we would much prefer to not have such an example to steer users toward a better UX approach.
I'll try my best to convince them! Maybe after your comment, it's easier π
Maybe you can help with another issue? π₯Ί .
As I said, my company wants the new UI as similiar as possible as the old one, so to the <DateTimePicker />
component, I had to use the StaticDateTimePicker
layout, cause it's the closest one to the old one (that looks like Mobile one, but the Mobile one opens a dialog, and that's not gonna happen).
It works perfectly, but when I finish selecting the minutes, the popper doesn't close. Maybe there's a workaround?
Yeah I know it's not the best way to do it, but it was the way I manage to make it work (almost haha)
I've updated the Sandbox. It's the last input!
I'll try my best to convince them! Maybe after your comment, it's easier π
I've discussed it with the team and we agreed to consider possibly adding a demo, maybe even one with masked input.
Maybe you can help with another issue? π₯Ί .
Have you checked the docs examples with changed viewRenderers
? They do not work for you?
Does the new DateTimePicker using a DigitalClock not work for you? π€
I'll try my best to convince them! Maybe after your comment, it's easier π
I've discussed it with the team and we agreed to consider possibly adding a demo, maybe even one with masked input.
Maybe you can help with another issue? π₯Ί .
Have you checked the docs examples with changed
viewRenderers
? They do not work for you?Does the new DateTimePicker using a DigitalClock not work for you? π€
Wow that's amazing! Thanks π
Not really, cause the clock opens on the side, and I need it to have the tabs, like mobile π«€
@LukasTy gentle ping π
thanks for the gentle ping β€οΈ @michelengelen
Hello, @KarineBrandelli Regarding
Maybe you can help with another issue? π₯Ί .
The StaticDateTimePicker
component is designed to be used without a popover/modal behavior (source). Notice that it doesn't have props like open
or closeOnSelect
that are available in the "non-static" components.
Maybe you could achieve something close to what you need by implementing a controlled StaticDateTimePicker
and pass it as a slot like you did, but I'm afraid it would be a big workaround that can easily become very complex and hard to maintain (a big gambiarra). Perhaps convincing your team to embrace the new UX is a safer path to take π
Hello, @KarineBrandelli Regarding
Maybe you can help with another issue? π₯Ί .
The
StaticDateTimePicker
component is designed to be used without a popover/modal behavior (source). Notice that it doesn't have props likeopen
orcloseOnSelect
that are available in the "non-static" components. Maybe you could achieve something close to what you need by implementing a controlledStaticDateTimePicker
and pass it as a slot like you did, but I'm afraid it would be a big workaround that can easily become very complex and hard to maintain (a big gambiarra). Perhaps convincing your team to embrace the new UX is a safer path to take π
Hey @arthurbalduini I appreciate you took the time to look at this!
Knowing my team, they will prefer the 'non modal behavior' to the new UX. I'll save this issue to argue with them in case some problem appears! π π«Ά
Just confirming that what you are asking is hardly doable with DesktopDateTimePicker
.
We will have this problem in mind when thinking of better ways to solve view renderer composition. π
Just confirming that what you are asking is hardly doable with
DesktopDateTimePicker
. We will have this problem in mind when thinking of better ways to solve view renderer composition. π
I appreciate it π
Summary
On the @material-ui/pickers, the input was empty. I'm migrating to @mui-x, and now when value is null, it renders the format by the locale chosen.
I've made a sandbox on how I'm using the component, can someone please help me?
Example Sandbox
Examples
No response
Motivation
No response
Search keywords: empty