Curious about this, especially since you say it will be MUCH faster. How much faster are we talking here?
Especially since I found the main limitations of any calendar to simply be Bubble’s ability to quickly load Bubble Data to into it (the actual painting of the repeating groups and dates have a slight delay, but waiting for data to fill in the calendar can be painful depending how the app’s data is set up). Would it allow for more optimized searches somehow?
It’s currently a full replacement for the custom RG-based calendar as I use it in GRUPZ. However, there are a few more features I’d like to add before publishing an initial version.
(These are rather advanced ideas, like a “chain” or “master/slave” mode - which would also enable range picking ACROSS calendar grids in a repeating group, a way to export/import styling parameters which are pretty extensive, and I also need to knock out a couple companion elements like separate DOW heading and month display modules.)
How are you loading the conditions into the calendar to show different colours / clickability? (such as loading data in another element and filtering on the client. Or pulling from the database and the conditions are built into the plugin somehow, etc)
Looks fast but also hard to know that without understanding how that data is setup and if there are a lot of conditions running on it
@gf_wolfer, Bubble’s not bad at grabbing single date or date range data at all. But there’s a ton of overhead in repeating groups (likely because of how they are designed to include and encapsulate any type of element).
What I’m showing in this iPhone videos is actually faster than the same sort of operation on Airbnb’s live site - and on a free test app.
Calendar Grid actually does a callback up into Bubble when the first date of the range is picked, so that you can do things like lookup the min/max nights for that starting date. And it waits until Bubble sends that data back to the plugin. It works faster than when Airbnb does this with React Dates and their insanely fast backend.
The problem with range picking in Bubble is (1) well, there IS no date range picker for Bubble except for the one I built for GRUPZ but (2) the problem with speed in THAT range picker is front-end (client-side) speed, NOT backend db access speed.
In its present and original version it is a calendar viewer/generator, date picker (single or multi — multi-date-picking is perhaps something with no application, but it does it), and Airbnb/VRBO/hotel/travel-style interactive date range picker (<— that part is the money shot).
Blocked dates and ranges shown conceptually represent a single thing’s availability, snapped to start of days.
I intend to extend this to a slightly different version to represent multiple things’ availability and/or times WITHIN the day.
@gf_wolfer, you just send it date ranges that should appear as blocked and/or start and end date list pairs representing the same thing (as you might have from an API) and/or single dates that represent an entire day of blockage and it does the rest (including optionally unblocking the first day of a blocking range if your start day blocks represent days that are available for “checkout”).
It also supports dynamic min/max night selections based on checkin date as you need in Airbnb/VRBO/GRUPZ type applications.
Basically, if you have this you have all the business logic for any daily availability booking system. (Obviously, the concept could be extended to any arbitrary time interval, but that’s step 2 or 3 for me. Currently, the main goal for me is to replace the RG-based calendar/range-picker used in GRUPZ calendars and booking widget with this superior plugin, while adding some features that make it more generally useful to other Bubble developers — e.g., I’ve no need for single datepicking, but I built that mode in as there are no Locale- and Timezone-aware datepickers for Bubble.)
The single-pane rangepicking feature that took me literally months to build in vanilla-ish Bubble when I first was working on GRUPZ are the main point of this though.
Are you going to implement any sort of RRules or ExDate functionality in this calendar plugin you’re building? Some would argue that they’re the only correct way to store business hours / recurring event information. As one can see, they’re quite powerful in ways that are not currently available in bubble.
Oh hai, @zelus_pudding: Well, CG Pro does not directly ingest iCal format data. It ingests dates, start/end dates and/or date ranges to understand what days it should show as blocked. It’s for day level date picking and display.
It has a built in facility (“day of week” or “DOW blocks”) to indicate days that should always be blocked (and this is done via an Action, so one could dynamically change those.
The use cases that CG Pro addresses are for day-level date picking as you’d have in a vacation rental, hotel or similar booking application.
What you’re talking about may be appropriate for its companion element “Time Grid”, which is still in development.
BTW Calendar Grid Pro is already available and you can find a lot more info about it here:
As for plugins that directly ingest iCal data… It’s MAYBE something I might add. Obviously, I’ve built a microservice that parses iCal for GRUPZ.com and returns date info to Bubble. The thing is, a feature like that would make these plugins EXTREMELY expensive, as then it’s a whole app, really, and we’re starting to talk about a level of value that’s up in the thousands, not tens or hundreds of dollars.