Change state before dehydration
For context, i have a DateTimePicker component for selecting the event's start date. If the user marks the
all_day checkbox, i need the component to set the hour to 00:00:00 but keeping the date. eg: 28/07/2023 -> 28/07/2023 00:00:00.
The thing is: I know i can do this with ->dehydrateStateUsing() but this will override the default dehydration process, which i need because it handles the timezone stuff behind the scenes..
How can i mutate the state before the dehydration process?17 Replies
you could do it in mutateFormDataBeforeSave(), right?
yeahh, but i then i need to copy the timezone handling to this method
1. the user selects
14:00 in the frontend
2. the data come as 11:00 (GMT -3 to UTC)
3. i mutate the data to 00:00 (GMT -3)
4. then i would need to shift the timezone again to UTC (21:00)
the 4th step is already part of the component dehydration process, if i could mutate the data before the dehydration process it would be easier and DRY
i need something like parent::dehydrateStateUsing($state) hahahaWouldn’t this automatically get handled at the laravel or db level unless your server isn’t UTC.
my laravel app and db are UTC, and my frontend component is
->timezone($user->timezone)I would think it would all just work if your make the field type datetime-local.
Let the browser worry about the conversion.
Then you only have to worry about converting it if the display is outside on an input.
hmm, i don't get it
if the user selects
15:00 in the frontend, the DateTimePicker component will consider that this time is in UTC by default, and save 15:00 in the database which is wrong.. i need the ->timezone($user>timezone) part to the Filament dehydration process to apply -3 hours to that time
also, if my record is 12:00 (UTC), does the browser knows it is UTC and apply +3 to that time?I could be wrong but I’m under the impression that datetime-local basically masks the value based on the users browser settings for their timezone.
Meaning anything they select would compensate the UTC offset, if im correct.
hmm i don't think so, datetime-local is only for displaying the data in the user format, it does not handle anything timezone-related
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local#:~:text=partydate%3D2024%2D06%2D01T08%3A30
also
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local#:~:text=One%20thing%20the%20datetime%2Dlocal%20input%20type%20doesn%27t%20provide%20is%20a%20way%20to%20set%20the%20time%20zone%20and/or%20locale%20of%20the%20date/time%20control.
👍
wait
Solution
Filament already have a
->beforeStateDehydrated()🤦♂️ 🤦♂️ 🤦♂️ 🤦♂️
Lol.
goddammit
Sorry for wasting you time. I’m new to this. 😂
well, VSCode autocompletion sucks, no surprises here...
Yes it does.