Invisible element generating error in debugger

I’ve been under the impression that invisible elements (marked as hidden, not styled to appear invisible) do not attempt to render their data source. @josh mentions this in a post:

"Invisible elements only fetch data if you force them to by referencing their data source. "

Today, I’m noticing this error:

However this element, is buried within a reusable element that is set to be hidden on page load, has no actions or conditions triggering it to be visible, and the debugger confirms it as being invisible. I understand what the error is telling me, and if the element were visible, it would be accurate, however the search too large is being triggered because other data has yet to be set (hence the entire thing being invisible.)

The element is an Expression from the Toolbox, and is referenced by a text element (again, this is all contained within an element not yet visible.)

PERHAPS related, the loading of this SPA seems to be slower than usual. If suddenly invisible elements are triggering searches before intended, I could see why my initial load would increase dramatically.

Anybody experiencing this, or have thoughts?

Thanks gang,


1 Like

This message is thrown by Bubble when the search query is too large. By search query we mean the list of constraints (there has to be a limit on what we can use to search for things). This can happen (it’s the usual case) when you do a IN constraint and send a long list as the value of the constraint (especially as lists get longer over time…).

I recommend working on your searches design to avoid this situation.

Thanks @emmanuel… I think I failed to convey my point.

I understand why that error is triggering – it is because (as you note) a huge list is being triggered. But the reason that is happening, is that this element is (at this stage) invisible, and the constraints that would limit that list have not been set. I was under the impression that invisible elements don’t fetch their data. If I go and make this section of the app visible, the error goes away because the proper constraints are in place.

Can you share a screenshot of search that is triggering this?

Sure, this is in an expression element which is in a reusable element that is hidden on page load.

These are for one of the searches, and the other two are similar.

Right, so if you look at your design, when parent group’s contact is empty, the list returns all the contact, which is a long list. So you could uncheck the box ‘Ignore empty constraints’, or only do the search when some conditions are met.

If we could ignore the search, for just a minute. :slight_smile:

Why is this search happening, when it is hidden?

What is the element?

It is an Expression element from the Toolbox plugin. It sits within a reusable element that is basically a panel within an spa. The entire panel is hidden on page load.

So you’re seeing this message with the debugger and while inspecting the element. Then, of course, the properties are being evaluated, regardless of the status visible or invisible.

If you don’t use the debugger, or don’t expect the element, the search won’t happen (you should fix the underlying issue anyway :slight_smile: )


Is the individual element also hidden on page load?
Does the error occur if the page is loaded without the ?debug_mode=true parameter?

Hey @mishav,

Thanks for checking in here.

Here is the sample I did for @emmanuel

If I mark the Expression element itself as hidden on page load, the search seems to happen, even if debug_mode is off…at least, that is what it looks like to me in the console (The output of the element is 21):

Maybe I am reading all this wrong?

Hi @mebeingken

I did some experimenting, it seems that dynamic expressions with search are run for hidden elements on page load, if the element’s value is used by another element, even if both elements are hidden. (For inside a reusable group).

The element itself doesn’t get its initialize or update code run.

However, if the element’s value isn’t used elsewhere, the search isn’t run.

Hopefully @emmanuel can comment on whether this is as per design, or needs fixing. :slight_smile:


Thanks @mishav.

I re-ran the test w/o using the expression element. I created a simple text element, using a search for its content, set it to hidden on page load, and removed all other elements from the page. If I load that page, I still see the search take place in the console.

With this happening, it is no wonder my spa takes forever to load. I hope this can be adjusted, otherwise I have to completely redesign the app, as I rely heavily on an assumption that hidden elements are not active unless referenced by something else (and that if those something else’s are also hidden, nothing takes place.)

That was indeed a performance glitch we introduced lately. We’ll push a fix today or tomorrow. Thanks for spotting this guys.


It’s fixed.

1 Like

Indeed it is! Thanks @emmanuel