Refactor WeekCalendar component + misc fixes

[davinotdavid]

Description of the Change

[TL;DR]:

• WeekCalendar had some big rewrites, now shows 24hrs in 60-min blocks always
• Added loading states while fetching remote events
• Updated LoadingSpinner and EventPopup styles and converted them from Tailwind to vanilla scoped CSS
• Updated UserCalendarSync to calculate the "time ago" properly, share a loading state with the calendar and bust cache to get the most up-to-date remote events
• Fixed a bug where availability slots in BookersPage would sometimes bleed over the availability time. We shouldn't show available slots if the slot duration go over the schedule's end time
• Updated styles for the slots with fixed colours. This was using the calendar colours before but Design team decided to do a fixed colour for now, for consistency.

Note

This is quite a big change so I'd appreciate some time to test the calendar out both in the Dashboard and in the BookersView with various Availability and calendar setups

--

[Explanation of why the issue happened and this PR's proposal on fixing it]:

• The core of the issue from Events created directly on a Calendar sometimes don't show in the Dashboard #1442 was that we were forcibly tossing out events / slots in the calendar that would fall outside of the calendar grid.
  • IIRC this was done because we were only rendering a "minimum calendar size" meaning the span of hours that we would show was dependent on a combination of the availability hours set on the schedule, slot duration and the earliest events in it.
  • This clearly isn't ideal as we may end up with a combination of availability hours and slot duration that would potentially not render enough calendar grid cells to hold an event block.
  • So then the idea here is to always show the full 24hrs span of grid cells regardless of schedule and use 15 min grid cells then align every event with the closest 15 min grid cell. The 15 min choice is because that's the smallest duration option and the increments of duration can be divided by 15 min as well.
  • The calendar is now much taller than before which requires scroll. To reduce some of the friction here, there's a scroll function that gets the id of the closest time block to the users current time and scrolls it into view. This will also be useful in case we want to show a horizontal line for the current "now" time.

Benefits

• Actually be able to see all events in a day
• A more accurate representation of time when manually syncing events
• Better feedback to the user on whether or not events are still being loaded

Screenshots

Light mode (Dashboard)

Light mode (Booker page)

Dark mode (Dashboard)

Dark mode (Booker page)

Applicable Issues

Fixes #1442

[MelissaAutumn]

Looks nice in action, I can't trigger the animation / scroll to stuff though.

For small mobile viewports I think we need to remove all left and right padding on the component.

[MelissaAutumn]

When does this happen, because in mobiler simulator it doesn't seem to scroll to anything.

[davinotdavid]

oh that was an interesting problem to solve for 😅 this is not an automatic scroll, it is actually just to be able to horizontally scroll the weekday header and the body since they are separate components (the calendar is a grid but the weekday header is in a separate div altogether).

[MelissaAutumn]

Well you fixed it so well I thought nothing was actually fixed haha.

[rwood-moz]

TBH, and just my opinion of course, but from a user point of view I liked it better when the calendar grid only shows the hours that you have marked as your availability. I find it seems like a lot of extra white space and a lot of scrolling required to see your availability hours (and I am concerned it will especially be too much on mobile).

[davinotdavid]

TBH, and just my opinion of course, but from a user point of view I liked it better when the calendar grid only shows the hours that you have marked as your availability. I find it seems like a lot of extra white space and a lot of scrolling required to see your availability hours (and I am concerned it will especially be too much on mobile).

@rwood-moz Good point! I tried to mitigate this by scrolling within the calendar to the current time so hopefully the requirements to keep scrolling around would be reduced. The problem with the previous approach though is the reason the ticket was created in the first place (remote events that couldn't fit in the calendar were not displayed at all)... it is a trade off of erroring on side of completeness vs keeping the calendar as small as possible.

I've submitted a request with the design team for a review next week to go deeper into this and see what's the best approach. If it is the previous implementation, happy to revert and document the shortcomings somewhere for support!

[devmount]

First: This is some heavy work you implemented here! Thanks so much for constantly syncing the views up with design 👏🏻 🎉

Alright, I tested this with different configurations. Here are some very opinionated findings, feel free to ignore those if you think they are not relevant / already discussed:

1. Clarity on the current position: It's nice, that the view automatically scrolls to the current time on page load. But it's also a bit confusing and "feels random". Maybe it'd be good to investigate how to make that visible to the user? E.g. drawing a dashed horizontal line where the current time is or sth like that
2. Default position: I also found myself scrolling back to the top every time I opened a bookers page. In most of the cases I don't look for meetings today/now, but the next days or week. So imho it makes more sense to default the scroll view to the first time an event occurs in that week. But again: This is highly subjective. Somebody else might have other needs here.
3. Timezone offsets: I configured my schedule in Europe/Berlin to be everyday from 9am to 2pm. Now I access the bookers page from America/Los_Angeles and see... nothing 😂 I navigate through the weeks and don't see a single event because I'm in the timezone gap and need to scroll upwards to see the available time slots.

In general I think we're definitely going in the right direction here. I just believe we need some more tools or visual hints, to omit confusion. E.g. I can think of making the grid depending on the schedule event duration. If 60min slots are configured, maybe a grid with 60min resolution would be sufficient.

[devmount]

Question: Is this meant to be scrolling to the exact position? Because on my end, it shows some previous events (it's currently 10.05 am in that screenshot):

If this is intended, all good!

[devmount]

Looks so much better now!! thanks