Refactoring custom calendar / date time picker

Alfred · 2024-09-26T22:38:43.991+00:00

Hi, I’m in the process of refactoring our custom date-time picker to make it more robust and improve support for time picking and better range handling. Our current picker is based on an early community-shared datepicker, which heavily relies on timestamps. While this works natively in Toddle, it's become extremely complex and somewhat fragile.I’ve been considering different approaches for the new version, but I’m still undecided. Should I rework how we handle timestamps, or rely more on the built-in Date object methods with custom actions and functions? Or is there another solution I might be overlooking?Our main goal is to support both date and time picking while keeping the component as Toddle-native as possible.Has anyone had good experiences, solutions, or learnings with building similar date pickers or calendars?

Alfred

9 months ago

Hi,
I’m in the process of refactoring our custom date-time picker to make it more robust and improve support for time picking and better range handling. Our current picker is based on an early community-shared datepicker, which heavily relies on timestamps. While this works natively in Toddle, it's become extremely complex and somewhat fragile.

I’ve been considering different approaches for the new version, but I’m still undecided. Should I rework how we handle timestamps, or rely more on the built-in Date object methods with custom actions and functions? Or is there another solution I might be overlooking?

Our main goal is to support both date and time picking while keeping the component as Toddle-native as possible.

Has anyone had good experiences, solutions, or learnings with building similar date pickers or calendars?
@Alfred
Hi,
I’m in the process of refactoring our custom date-time picker to make it more robust and improve support for time picking and better range handling. Our current picker is based on an early community-shared datepicker, which heavily relies on timestamps. While this works natively in Toddle, it's become extremely complex and somewhat fragile.

I’ve been considering different approaches for the new version, but I’m still undecided. Should I rework how we handle timestamps, or rely more on the built-in Date object methods with custom actions and functions? Or is there another solution I might be overlooking?

Our main goal is to support both date and time picking while keeping the component as Toddle-native as possible.

Has anyone had good experiences, solutions, or learnings with building similar date pickers or calendars?
Lucas G

9 months ago

What troubles are you finding with timestamps? I'm in the middle of adding more booking functionalities to my calendar and was originally going with a custom model where I store day, month, and year
Lucas G

9 months ago

Or rather I should clarify that my calendar was originally built using a custom model but I was wondering if I should change it/if something else could work better
So far I haven't had issues with my setup though
Alfred

9 months ago

Currently, our old datepicker component consists of over 40 formulas for calculating timestamps, handling leap years, formatting timestamps, accounting for different month lengths, and converting timestamps to days, weeks, months, etc. It works fine and is fully Toddle Native (whichs is awesome), with the original functionality foundation built by @ . Honestly, I think it’s an incredible build, and I wouldn’t have been able to get this far without that foundation.

That said, as I’ve been working on it, I’ve found it a bit challenging to maintain, and I occasionally run into issues when trying to add new functionality because everything is so closely coupled. While the solution works, I’m wondering if there’s a way we could simplify it for easier maintenance going forward. I just feel like handling all this formatting ourselves adds some complexity.
Lucas G

9 months ago

It really depends on the functionality you need
I do agree that timestamps may not be the best due to all the formatting you mentioned. Not even accounting for time zones
Alfred

9 months ago

All these formulas should ideally have their own package for managing, handling, and formatting timestamps, but then it wouldn’t be possible to utilize them in other packages haha
Alfred

9 months ago

I’ve also considered starting from scratch and rebuilding all the formulas to ensure I fully understand the structure and logic inside and out.
Lucas G

9 months ago

What functionality do you need to ensure you have?
In the screenshots I see different components
Is it all one
Or are they individually used
Alfred

9 months ago

My component has two main variants: one with a range (the big one) and one without. The smaller panels serve as popovers triggered from the header, allowing users to change months and years more quickly and easily
Alfred

9 months ago

Much of the same logic is used as in the datepicker from the Preline UI library - https://preline.co/docs/datepicker.html
Lucas G

9 months ago

Do your month and year header/popovers also use timestamps?
No right
Lucas G

9 months ago

Over 40 formulas sounds crazy though, there is likely room for refactoring there. For context, this used 1 small custom formula https://discord.com/channels/972416966683926538/972416966683926541/1284235221562163304
@Alfred
Currently, our old datepicker component consists of over 40 formulas for calculating timestamps, handling leap years, formatting timestamps, accounting for different month lengths, and converting timestamps to days, weeks, months, etc. It works fine and is fully Toddle Native (whichs is awesome), with the original functionality foundation built by @ . Honestly, I think it’s an incredible build, and I wouldn’t have been able to get this far without that foundation.

That said, as I’ve been working on it, I’ve found it a bit challenging to maintain, and I occasionally run into issues when trying to add new functionality because everything is so closely coupled. While the solution works, I’m wondering if there’s a way we could simplify it for easier maintenance going forward. I just feel like handling all this formatting ourselves adds some complexity.
gazinhio

9 months ago

I agree, that original date picker was developed over a year ago when we didn't have access to custom code, packages or project formulas so it was built within those limitations - mainly to prove it could be done at the time. As @Lucas G says, the timezone issue with timestamps means it's best to work with JS' built-in date functions so custom code is required if working specifically with times. With all of that said, I still use the original in my apps with very little changes excepting design, as well as a full calendar component that is derived from the original date picker. Whilst it works, I won't be doing a rebuild. I do think having a lot of these date and time formulas would be great as part of the built-in formulas as when building business apps, dates are key. Just my zwei cents.
Lucas G

9 months ago

That's good context
Lucas G

9 months ago

My head would do better with fewer functions/formulas so I would consider rebuilding to use JS, if only for a simpler build.
lol
It is always interesting to hear about how other people approached a problem
@Lucas G
Over 40 formulas sounds crazy though, there is likely room for refactoring there. For context, this used 1 small custom formula https://discord.com/channels/972416966683926538/972416966683926541/1284235221562163304
gazinhio

9 months ago

Well I had to build absolutely everything from scratch at the time, literally an entire date formula library. Other than the Now formula and turning a date into a timestamp and back again there was nothing else and we didnt have custom code back then either. You mention 1 small custom formula, I would be very interested to know what you did there?
@gazinhio
Well I had to build absolutely everything from scratch at the time, literally an entire date formula library. Other than the Now formula and turning a date into a timestamp and back again there was nothing else and we didnt have custom code back then either. You mention 1 small custom formula, I would be very interested to know what you did there?
Lucas G

9 months ago

And you are a damn beast for having built all that in pure toddle functions. Especially considering they've added more since then
It's crazy
@gazinhio
Well I had to build absolutely everything from scratch at the time, literally an entire date formula library. Other than the Now formula and turning a date into a timestamp and back again there was nothing else and we didnt have custom code back then either. You mention 1 small custom formula, I would be very interested to know what you did there?
Lucas G

9 months ago

Sure, here it is:
I use this to render the calendar
It returns the first and last days of the month (weekdays)
I have a variable that tracks the current month and year and that feeds into this
And then I repeat over it like this:
Lucas G

9 months ago

Then I have a separate custom formula to generate time slots for a given time range
Since my use case is a booking calendar
gazinhio

9 months ago

@Alfred I've discovered a bug in the date picker just in case you come across it.

It effectively gives you 32 days in October because, here in the UK anyway, on the last Saturday of the month (this year on the 27th) we bring in daylight savings time where we put the clocks back an hour. So the calendar works by using no time so effectively 00:00 which is midnight. As daylight savings pushes the time back an hour, when it adds a day from the 27th, its effectively still 23:00 on the 27th so it gives you another 27th of October on the calendar, though only for October.

The fix is to make the default time 12pm (midday) and therefore adding or taking an hour on any day won't effect it either way. This requires a custom code formula and a change to the AddDays formula to call that formula. I put a couple of screenshots to show you the change.
gazinhio

9 months ago
gazinhio

9 months ago

Here's the code in case you want to copy & paste it :

const date = new Date(args.timestamp);
let hour = args.hour;

date.setHours(hour, 0, 0, 0);

return date.getTime();
Alfred

9 months ago

I spent the last two days refactoring our date picker with custom functions for managing date objects. It now uses a compound composable structure, allowing individual date, month, year, and time pickers to be combined or used separately within the root context component - https://www.loom.com/share/184b47513a9f437ab65baefee1247ac4
Alfred

9 months ago

I still need to finalize the implementation of relative popovers for positioning the month and year pickers in the headers, and possibly also add support for a range picker.
@Alfred
I spent the last two days refactoring our date picker with custom functions for managing date objects. It now uses a compound composable structure, allowing individual date, month, year, and time pickers to be combined or used separately within the root context component - https://www.loom.com/share/184b47513a9f437ab65baefee1247ac4
Lucas G

9 months ago

Looks good!
Sounds like it is a lot more manageable now
Alfred

9 months ago

ended with just a fixed popover in the middle with auto margins - https://www.loom.com/share/a8f83051b9cc4341973d8d5619186e72?sid=04dcbfc7-323e-47b8-a8e6-7718e3d9494a
Alfred

9 months ago

I have created eight formulas, but they are in a separate package. I'm considering adding more default built-in methods for date objects manipulation. These methods primarily handle adding or subtracting time from date objects or generating arrays of date objects for day, month, and year period views.

Refactoring custom calendar / date time picker

Alfred

Lucas G

Lucas G

Alfred

Lucas G

Alfred

Alfred

Lucas G

Alfred

Alfred

Lucas G

Lucas G

gazinhio

Lucas G

Lucas G

gazinhio

Lucas G

Lucas G

Lucas G

gazinhio

gazinhio

gazinhio

Alfred

Alfred

Lucas G

Alfred

Alfred