Multiple Similar Do a Search For's

[nico.dicagno]

Hello!
In my app i am creating a dynamic calendar from first-principles.

I have a repeating group with each cell representing a day and logic setup to fully mimic a calendar

For each day I need to retrieve two data types, and there are 3 Time-slots per day. These dont necessarily exist for all days/time slots; the searches can return empty. The first time I built the page, I put “do a search for”'s in each cell. That adds up to a whole lot of “Do a Searches” on page load and every time the month is changed. It is also a search in the datatype with the largest entry count.
This felt very dumb, because all the do a search for’s are very similar (eg, Date is only a few days apart and Time slot is between 1-3). Why was i making bubble do all these searches? I realised i could just make one query by searching all Dates in a particular month and all time slots. With a single search i would have all the data i need to display on the page in a list. But after that what? I thought about using client side filtering to filter from the full month data list the individual day data. They are simple filtering actions (Date=Date, Time slot=1-3) on a relatively small list (<90)… but there are around 100 filtering actions (6 per day-cell), so that doesn’t feel right.

I feel like both approaches are not optimal… i’ve been stumped all day. Which one should i pursue? Is there a third option which is better and i’m not seeing?

Have a great day and thanks in advance

[keith]

Yeah, doing this in vanilla Bubble is… d… well, not very efficient. You’re going to have to resort to custom code here.

I actually built something similar in vanilla Bubble, but it was so painfully slow that it was unviable as a commercial solution. (That being said, I actually had paid customers of my first Bubble-native version, warts and all.)

I have two paid plugins that help with this as a result: Calendar Grid Pro (a very novel date/date-range picker that actually inspired some of Airbnb’s work in that area – it uses moment.js) and Parallels (a more modern pure data-processing plugin that leverages Luxon to do MOST of the same tricks, but has no visual front-end.).

Since you’re the DIY type, you won’t be interested in the paid plugins (though I’d encourage you to test them out and follow my videos about them), you’ll probably just want to read/watch everything I’ve ever published about dates. Search “@keith dates” to learn more.

In short, you’re going to have to learn to code some stuff. (It’s not that hard, really.)

[nico.dicagno]

Hi Keith, I have actually stumbled upon your Calendar Grid Pro plugin and a few of your forum posts! Thank you for everything. I’ll look more in depth at your forum posts.
I’m all for paid plugins but the only reason why I didn’t go for Calendar Grid pro is because i need an event displayer calendar, not a date picker. I will definitely look into integrating Parallels in the back-end, great plugin.

I’m also all for coding. Integrating coding in the areas where bubble is d… lacking, feels like a great idea. (I absolutely love bubble btw ahha) However i have no clue where/how/with what to set up the codes… We have the java plugin toolbox for some front-end data/numerical manipulation. Is that what you mean by coding? Is there a way to get coding integrated in the back-end or in between the front and back end?

[rojas.mora.diego]

Hey @nico.dicagno , did you find any insight on your topic? If I understand it well your question is basically if it’s better to do a search for the big bucket entries needed (day of the month in your case) to a RG maybe and then referencing each part of your table to that RG by filtering it client-side to each section based on each of their identifier, or in the other case if it’s better to just “do a search for” specifially for all the sctions or your calendar as you have done. Right? well, I have basically have the same question, so just wondering how good is your app performing and/or if there are any other way to do this that is more performant. My general though is that server-side searches are always faster, so I thought as you did makes sense, but not sure at this point.

Thanks!
Diego

[nico.dicagno]

I never ended up doing a rigorous analysis of whether filtering searches on the client-side was actually quicker than multiple individual server-side searches, at least in my particular case. It seemed that client side filtering had potential, but i ended up going for another solution which worked much better and in my opinion was much more elegant too. This can be another tool in your arsenal which you may consider when building in bubble.

These are a few screenshots of calendars with dummy data just to give an idea of what i was trying to build.

Each calendar day has a set of pre-determined slots which can each have different status, and slots can also be merged into one.

The key was in realising that there was no need to download 1000s of individual dataThings into the page.
The calendar had a general structure, and there were only some blanks to fill with text data / conditional formatting.
I ended up creating a dataType which compressed a month’s view data into a single Thing, with a few text fields that represent the formatting of a particular calendar view.
Eg: ‘0,0,0,0,1,3,0,2,4’ for color coding
‘21:00 - 00:00, , , 15:00 - 23:00, 23:00-01:00’ for time, etc.
On the repeating groups for days and slots, I would extract the formatting data for that particular cell with RegEx

The dataThings which actually cause the slot’s formatting to be how it is do not need to be on the calendar! There is no need for them to be. As long as you can format the frontend correctly, the dataThings can stay in the database.

You just have to make sure that when data changes, compressors are updated with the corresponding value.
So when users makes an action that changes data, you can use ‘optimistic rendering’ to change the frontend and send some parameters to a backend API which searches for the dataThing in question and changes it. No need to change the dataThing directly from the frontend.
If the user clicks on a particular slot and more data needs to be fetched, then you run a search with the correct parameters and retrieve the dataThings needed.

With this approach, i got the calendar to be relatively quick. Before this method, a calendar might take 10-20 seconds to load, as well as when the month’s view is changed. Now this is down to 3-4 seconds.

I believe this is a very powerful trick if you care about performance and want to summarise the data from many dataThings into a single one (and also don’t care too much about WU). It does make stuff slightly more complicated to manage, as you really are separating the frontend from the backend, but if you document what you’re doing well enough, its really not that bad. Like most things, its all a tradeoff and you gotta balance it with your needs.