Basic directory of urban planning organizations in LA

Hi! I just launched the MVP of my first “complete” bubble site:

Coburb is a hub for LA urbanists - A collection of urban planning related organizations in Los Angeles

It’s pretty basic, but still happy with how it turned out so far. It took me a while to get the filtering and searching working properly. I’d like to add some more features eventually to make it more like but just taking baby steps to get there :slight_smile:


@jayne1 Loads quickly, looks great, nice job!

I am curious if you’d be willing to share the secret to getting a site to load quickly? Very impressive load speed with the repeating group and images etc.

Not built on Bubble, but good work !

Nice, and it does seem fast. I’m curious how you set up the industry filter with the list of checkboxes.

The method for searching a list based on a list isn’t always clear… but it’s a common need, for example searching blog posts based on subject tags, products based on attributes, or in your case organizations based on industries.

In my case the best I could come up with in Bubble is using advanced filters and the “intersect with” function, but I continue to wonder if there is a faster or more efficient way.

Thanks, not sure why you don’t think it was built on Bubble, but it definitely was. Even still has the “built on bubble” tag in the corner cause I don’t want to pay to upgrade yet :sweat_smile:


Ah, woops. I clicked on the other link. :roll_eyes:

Sorry. In that case, the Bubble app looks nice!

1 Like

@boston85719 @ed727

Glad it seems to be loading fast for you guys, I was worried the images might slow things down for people. All the hero images are “shapes” with an image as a background style instead of an actual “image” component. I’m not sure if that helps with load time at all.

As far as the searching/filtering goes I agree, it was not super clear even after reading a bunch of forum posts and tutorials. I think the main trick is in using custom states and structuring the data to be easy to query.

Data Structure:

  • Each organization thing has a list of industries it belongs to
  • Each industry thing also has a list of organizations that are associated with it
  • I think this makes it easier to do a search for organizations in a specific industry

Custom States

  • I have 4 custom states associated with different components
  • Search group has a custom state called “found” which is a list of orgs
  • Industry filter has a custom state called “selected” which is a list of industries
  • Org repeating group has a custom state called “refined” which is a list of orgs, which is basically the intersection of the “found” and “selected” states.
  • Org repeating group also has a custom state called “empty” which is just a yes/no for whether or not to show an empty state when no results are found.


  • When the user searches or clicks on a filter checkbox, each custom state is updated to reflect the change and then update the “refined” state to get the new overlapping elements.


  • Org repeating group has 3 conditions to decide where to get it’s data source from, based on whether there is anything in the custom states and if no results are found.

Hopefully, that makes some sense! I’m not sure if it’s the “best” way to do it, but it was the only way that worked for me. I’m also not sure how it will work if I add more filters yet. Let me know if you have more questions :slight_smile:

1 Like

Thank you for this explanation! It’s always interesting to see how others approach solutions to similar problems.

In my case, I’ve done things slightly differently…

  • I have “events” (database of things) and “subject tags” (an option set). Each event thing has a field that lists the relevant subject tags.
  • When searching for events based on subject tags, I’m asking Bubble to… search the entire events dataset and return to me the events containing one or more of these subject tags. In your setup, it’s flipped, in that you’re asking Bubble… give me all the organizations that are listed in the industries I’ve selected. I believe your approach runs faster – I recall reading that it’s faster to return a list of something contained within a thing, vs. searching for specific things that match an attribute.
  • That said, for a large database, I think it gets hard to do this double connection (where thing type A is connected to thing type B, and vice versa) from an entry and maintenance perspective, since if you assign or change a connection it would need to be done to two datasets rather than one. Also, I recall reading in a performance thread that there are limitations on how large a list within a thing can be, so if a dataset has thousands of items, it may be too many to list the relevant things within a subject tag’s entry.
  • I approached searching a little differently than you. Rather than using conditions to show different RGs, I have a single RG with search constraints for the things that can be done server side (in your case, the searchbox), along with advanced filters for the “intersect with” function to match events and subject tags. Empty constraints are ignored, so the entire dataset returned if nothing is selected.

Thanks again for sharing your work and the behind the scenes setup. It made me see things from a different perspective, and in addition I now think I know why your site’s speed is a little faster than mine.

Yeah, I had a few confusing bugs at first where I didn’t realize I had to update it in both places. Now that I created an “add organization” form it automatically adds it in both places, but I haven’t made the “edit organization” form yet so for now if I need to edit them it’s a manual process. I guess that’s the next feature I need to work on!

That’s interesting, I’m curious what the limit is. I can see that could be an issue with a huge data set. Hopefully, I don’t run into it anytime soon but will keep an eye out as my list gets bigger :slight_smile:

Hi, re: short lists vs. long lists, it’s mentioned in this Q&A thread…

Also on list limitations, it’s 10,000 per the reference guide: Introduction - Bubble Docs

…but commentary in the threads say to stay away from longer lists.

In discussions about database structuring I’ve seen people debating which datatype should be the parent and which the child, or do it both ways, and the tradeoffs between speed and scalability. “Traditional” database best practice says to do it only one way and to choose the parent correctly. I’d say that if you think your database will scale to lots of entries, then to pay some attention to it. But if the dataset will remain limited, then it really doesn’t matter that much.

1 Like

Congrats! Looks awesome!