Editor is Too Slow When Using Many Elements – How to Improve Performance?

[ed19]

Yep already done most of this! I’ve done a fair bit of work moving pages around so am relatively well informed with regards to remapping functions. The main complication I’m having is page-level states or workflows needing to be shifted across, hopefully the end justifies the means.

[emir.ozgun]

@boston85719

Sorry mate, but using reusables for an SPA as the ‘pages/views’ is ESSENTIAL

No it is not, best practice is to have maximum flexibility with minimum overhead, who put the idea of reusables as pages idea but it is straight out wrong.

@boston85719

Don’t…reusables should for the most part only ever be a group, and the reason being is flexibility

It can be very well used as a popup, who says these things ?. I believe there is a place the same place that daisy chain filtering idea came up.

Think about it, idea of page as reusables was there when a reusable has had only 1 property

[georgecollier]

@boston85719

Also, option displays should be lowercase to be more compatible with URL.

Option set displays with spaces / regardless of capitlisation work when using Get an option from page URL

@emir.ozgun

best practice is to have maximum flexibility with minimum overhead

@emir.ozgun

reusables as pages idea is straight out wrong

[emir.ozgun]

I have pages as reusables, I have pages that are not reusables but content is all reusables. Just these things are limiters not ideas. Similarly I have popup as a reusable as well as group reusable inside a popup

[randomanon]

@georgecollier

CleanShot 2025-04-10 at 13.55.22@2x961×1310 64.5 KB

I raise you

[boston85719]

It is not about modularity for me. I use the reusables as ‘pages/views’ for SPA or pages like a dashboard for the main purpose of limiting editor slow down. I use reusables for modularity when I create features or functions as groups and plan to use them in more than one area of the app, or just prefer the ease of maintenance by the stand alone feature being just a reusable and surrounded by no clutter from other features/element functions.

@georgecollier

Option set displays with spaces / regardless of capitlisation work when using Get an option from page URL

That is true, and I will be lazy in my response and just paste in what AI says when asked (side note, this would be the exact way I personally would have explained it and I do not know if the AI just decided to learn me well enough to produce a response I agree with )

@emir.ozgun

No it is not, best practice is to have maximum flexibility with minimum overhead, who put the idea of reusables as pages idea but it is straight out wrong.

I think you misunderstand the concept of reusables as pages. The concept is for an SPA, which is a Single Page Application, that when you change the URL to essentially ‘navigate’ the user, and so need to change the view or page the user sees based on the URL and the expectation of navigating to a new page, that is built out as a reusable element.

In terms of who put the idea of reusables as pages in this way, I can not say for sure who was the first, but you can maybe blame me for it. The main reason for it, and why I tested it myself as a theory to reduce the amount of times my editor crashed some 5 years ago, and when finding out it solved the issue of an editor crashing, I began advising people to use the method in order to avoid editor crashes when building SPAs or pages like dashboards or just large complex pages with functions or features that could be decoupled easily.

@emir.ozgun

It can be very well used as a popup, who says these things ?

I do…the logic stands. There is no reason to create a reusable element that is just a popup if you plan on using it in more than one place. The reason I make this statement is from my years of experience struggling with decisions made earlier in a build when it comes to a later point in the build and there needs to be a change made. It also just allows for more flexibility in how you can use a reusable because if you create a reusable that is a popup or a floating group, then as I explained previously, you can only in the app ever use them as a popup or a floating group. However, if it is reusable as a group, that reusable can be used as every single type of container in the editor, so a Group, Popup, Group Focus, Floating Group, in a Repeating Group…so, I don’t know about you, but the flexibility of how to use it in potentially 5 different container types compared to being locked into just one container type means for me, I would prefer for the most part to just always create a reusable as a group.

@emir.ozgun

I believe there is a place the same place that daisy chain filtering idea came up.

It absolutely is not

@emir.ozgun

I have pages as reusables, I have pages that are not reusables but content is all reusables

Yes of course. This is what we have been speaking about…it is not possible to have a reusable that is a page, so this sounds like you are doing what is advised.

@emir.ozgun

I have popup as a reusable as well as group reusable inside a popup

yes, and my advice is that as I’ve described to have a group reusable inside a popup on the page for the flexibility of how to use it

[emir.ozgun]

@boston85719

you misunderstand the concept of reusables as pages. The concept is for an SPA

You lost me there

[emir.ozgun]

I don’t know you are being sincere or not but I perceive this as very disrespectful, as an act of passive agressive thing. Some peple act like 5 years old when they get into an argument, like being in the state of intermittently forgetting things.

[code-escapee]

@boston85719

@georgecollier

Option set displays with spaces / regardless of capitlisation work when using Get an option from page URL

That is true, and I will be lazy in my response and just paste in what AI says when asked (side note, this would be the exact way I personally would have explained it and I do not know if the AI just decided to learn me well enough to produce a response I agree with )

your question wasn’t worded precisely. It’s not just for a regular URL; it’s for a view so all of the reasons not to dont apply for anything after the question mark. No option set name is going to be less readable then the gclid or fbclid…

Using option set names/displays that are descriptive of the view itself and readable at a glance (ie, spaces) are super helpful to be able to quickly look at a view and understand whats going on. I’ve even capitlized ENTIRE words in a view to stress something about the view.

[mitchbaylis]

Option sets work fine in urls as is.

In cases where they don’t because I wanted to use special characters or something like that I just add a parameter to the option set and then reference that in the url and lookup instead.

[boston85719]

@code-escapee

it’s for a view so all of the reasons not to dont apply for anything after the question mark.

That is one way to look at things yes, that in special cases where best practices do not need to be considered, you do not need to follow the guidelines of a best practice.

But strange enough for me, following best practices no matter which scenario I am in allows me to follow those best practices every time I need them as if it is second nature. Being consistent I believe is key doing a job well over and over, so I try to keep the same approach no matter the need. And for me personally, I do not only use option sets in parameters nor do I create my views as only parameters. I use path lists a lot more than parameters now because parameters are no good for SEO. But of course, there are times when I take the lazy approach and use a parameter as the page doesn’t require SEO benefits, but I am not attempting to change how I name option sets and keep track of whether it is used as a parameter or a path list.

@code-escapee

No option set name is going to be less readable then the gclid or fbclid…

nobody is sharing urls with tracking parameters added in…I really don’t understand the point of the comment

@code-escapee

readable at a glance (ie, spaces) are super helpful to be able to quickly look at a view and understand whats going on.

Great point. Yes, for you the developer it is easier for you to read it in the editor (although I find eat-chocolate just as readable as EAT CHOCOLATE), but including a space for something that will be used in a URL is just bad practice since the URL encoded value of a space is equivalent to %20 so the EAT CHOCOLATE now becomes EAT%20CHOCOLATE in the URL which is not at all readable and makes life a lot more difficult for the developer to structure the URL to use in areas that it needs to be shared.

I tried some more precisely worded questions to try and get a different answer

when should I use a space in a word or sentence that will be placed into a url

when should I capitalize words or letters from sentences or strings that will be used in the url

when should I not use lowercase letters that will be in the url?

when should I use a space instead of a - for strings in url?

Hopefully all of this helps clear up some confusion for other users who may stumble into this post and want to know best practices and things to avoid. I wish when I first got started somebody with 7+ years of experience working with this type of stuff could have laid it out so plainly for me and I didn’t need to spend so much time reading blog posts and articles on the subject plus playing around with different approaches in Bubble leading to issues and headaches. Just some free advice on things to avoid and best practices that are easily implemented, but of course, everybody is welcome to use their own form of ‘best practices’ as they’ve come up with them and they work for them.

@mitchbaylis

Option sets work fine in urls as is.

In cases where they don’t because I wanted to use special characters or something like that I just add a parameter to the option set and then reference that in the url and lookup instead.

all true, but the use of the parameter on the option set that you alter the display value to be more URL friendly, doesn’t help you to make use of the feature of the Get Data from URL that I still believe many many developers out there do not know. I found this out when explaining this to other Bootcamp instructors some 5 years ago and even recently on the forum a trainer with more time on platform than me had not discovered yet. If you want Bubble to know what option you are using without needing to expand your expression you have to use the display value since that is THE ID OF THE OPTION that bubble uses internally.

Here is a video explaining and demonstrating the differences between the best practice and the other approaches. Hopefully this helps some new users understanding how they should set things up from the beginning and knowing why.

[mitchbaylis]

you can just use

all options > filtered to > option param = get data from url : first item

when using the param in an option instead of the display in the url

this lookup works will for other places in the app also - I use it for tabs, dropdowns and filters a lot.

for instance - user wants an “all” option for an option set.

you could add “all” as an option but then it becomes a filterable value and the searches will fail since data will not have all but instead have “todo” or “complete” (example)

you could add conditionals to do a search without using the option filter when the value is “all” but that becomes messy with several options used in a search…

you could save the option to a state and add conditions to save empty if it is “all” - therefore the search filters correctly still since all will be empty

or you could change the dropdown to text “all > converted to list > plus list > list of options display”

then in the search you just use constraint option = all option > filtered to > this option display = dropdown value > first item" - I usually prefer this option since it is the simplest

I’m sure there are also other ways to do it. but this just shows how flexible bubble is and that there are many ways to achieve the same outcome and it largely comes down to experience and preference.

what also is a great solution for a small app is often a terrible solution for a large app. And as your app scales you will often need to rebuild parts of it to handle the greater scale.

ie an option set for file type
works well when there’s 10 or so types in a small app
works less well when there’s 50
works horribly when there’s 100 (better as data than an option)

I recently had to change an option set for file type to data in an app because it had outgrown the option - but it was the right use of the option initially (only had 3 types), it’s just that the use scaled beyond it little by little and it eventually had 60 types.

could I have foreseen it getting to 60 types? maybe. should I have used a data instead of option initially - maybe. But I made the choices at the time given my best guess of it’s use in the future - which served it well for about 4 years… but now 4 years later it needed a new solution.

The same applies to reuseables - you may not need them yet. But one day you might. You don’t need to create hundreds of reuseables for everything on the page - but if you end up rebuilding the same things over and over… well maybe think about reuseables.

[randomanon]

@code-escapee

Using option set names/displays that are descriptive of the view itself and readable at a glance (ie, spaces) are super helpful to be able to quickly look at a view and understand whats going on. I’ve even capitlized ENTIRE words in a view to stress something about the view.

@mitchbaylis

Option sets work fine in urls as is.

In cases where they don’t because I wanted to use special characters or something like that I just add a parameter to the option set and then reference that in the url and lookup instead.

You can also do a quick find&replace of the space and change it to %20. Not good for SEO but for a page of your app, it really doesn’t matter whatsoever. Or find&replace the space to a hyphen. Whatever.

[boston85719]

@mitchbaylis

for instance - user wants an “all” option for an option set.

you could add “all” as an option but then it becomes a filterable value and the searches will fail since data will not have all but instead have “todo” or “complete” (example)

you could add conditionals to do a search without using the option filter when the value is “all” but that becomes messy with several options used in a search…

you could save the option to a state and add conditions to save empty if it is “all” - therefore the search filters correctly still since all will be empty

or you could change the dropdown to text “all > converted to list > plus list > list of options display”

then in the search you just use constraint option = all option > filtered to > this option display = dropdown value > first item" - I usually prefer this option since it is the simplest

I would opt for the setting a state as empty conditionally if the option selected is the ‘all’