How Would You Do it? Build a Booking Calendar

[dhew]

Hi,

I’ve been working on this little challenge a few days and have gone through multiple concepts for how it works and drafts of the actual app, but am wondering if you’d share your thoughts and ideas. I’m sure there is a better, more efficient way to build the final product than what I’m currently doing, so please let me know if you have a better way for some or all of it!

I already have most of the backend built in Supabase, but everything is changeable and there are no bad ideas. I’m looking for advice, general approaches, examples, etc. more than specific problem solving at this point.

Basic concept:
Build a calendar-based ‘booking’ system to allow users to “book” one (of several) unique, physical assets for a set time block. In my specific case, users are booking boats, but there is nothing special about this (they could be cars or hotel rooms).

There are 9 boats currently. There are 3 time slots available each day for a boat to be booked. And the boats can be booked on any day of the week. In total, that is 189 individual booking ‘slots.’

There are a few complications I’m skipping over (boats can break and be taken ‘out of service’ at any point, some time slots are not available on some days, etc.).

The main issue I’m facing is how to build the front end, “booking” view, efficiently. Ideally users would see a ‘week view’ grid with 3 big rows, one for each time slot (9am - noon, noon - 4pm, 4pm - 8pm), with smaller rows nested inside for each boat, then columns for each of the week days:

But I’m struggling to build this in weweb. I have done 3 versions (using both the built in calendar element and hand-built grids), but am struggling with:

1. Stitching the various data pieces together (without using ~200 lookups/filterbykey/etc.)
2. Finding the right balance of flexibility with the data structure (to allow an admin to change the number and/or availability of boats, to add one-off “blackout” days, etc.).

I even considered (read: built) a massive workflow to just iterate through all the variations to create empty placeholder ‘bookings’ users could just ‘transfer’ into their name. But I stopped when I realized how fast that would escalate into (tens of) thousands of database objects, most of which would likely never be used!

---

Hoping someone might have some ideas or tips on how to combine these four different pieces of data (an individual booking, consisting of a boat, on a specific day of week, and within one of 3 pre-set times of day).

[Agustin_Carozo]

Hi Daniel, this is amazing!

I love how you are trying to figure this out.

I don’t have a specific tip for you right now, but would you consider creating a short video walking us through how you managed to create this structure?

I think it could be really helpful for others trying to achieve your same results.

Cheers!

[Broberto]

Hi, can you post your DB schema? I talk about not using lookups in the following post.

Become a Supabase Magician in WeWeb (Tutorial With Examples) – Broberto

[dhew]

Hi,

Sure. See below. Please keep in mind nothing here is totally fixed/I tried to design it with flexibility in mind for the future.

Perhaps the only thing of note here is I thought using a join table for boats + schedules (i.e., when ‘boats’ can be ‘booked’) would be the most flexible in the long run, to allow the Admin to change boat availability more easily (see note at bottom).

Also, I’ve read that post of yours a couple times now–thank you for writing it! I’ve implemented some of your tips already (such as using the ‘advanced’ field of collections) and they were very helpful.

Note from above:
I’ve read that calendar systems should store repeating events as single DB entries, then use an ‘exception’ event type to ‘override’ a specific occurrence of a recurring event, should the user need to cancel one instance but not the whole series of the recurring event. I tried to apply that same logic with this ‘schedule’ design (so admin could void a single schedule day/time without changing the long-term availability schedule), but TBD if that is a good idea (and how exactly it would work here).