More clever way to compare list?

How do you check if list A = list B in Bubble?

if (B⊂A) & (A⊂B), then A =B . => in Bubble’s language, (A contains list B) and (B contains list A) => this one is the simplest I found. But may be I’m wrong. tell me .

And many other variants of this same workaround. Isn’t it too laborious?
There should be more clever ways to chech if list A and B are identical without those complicated solution. Bubble definitely needs to improve its way of handling list. if you’re Ok with that, vote on the ideaboard : Linke here :point_right:More clever way to compare list

1 Like

What about this is complicated? Are you proposing another way or just want it to be simpler than a compare? (Note: your approach doesnt seem to be correct and you should use count as a seperate conditional to stop the compare operation before intersecting)

1 Like

what I meant is a simpler way … like one simple operator.

For the expression, my bad, I wrote it quickly : Here it is :
1- A and B have same number of items and their intersection has same number of items too => In Bubble’s language, (A intersect with B)'s list of items :count is A’s list of items count and A’s list of items:count is B’s list of items:count
(That is a version without using the “contains list” operator, but too complicated)

2- if (B⊂A) & (A⊂B), then A =B. => in Bubble’s language, (A contains list B) and (B contains list A) => this one is the simplest I found. But may be I’m wrong. tell me.

3- if (B⊂A) and (A & B have same number of items) then there are identical => in Bubble’s language, (A contains list B) and (A’s list of items :count is B’s list of item :count)

And you could go on and on and on with some expressions being more optimized in terms of computation speed and WU consumption than others. What I mean is , you always have to combine at least 2 expressions to do these workarounds, while Bubble has the genius and power to simplify this, just like they did for the “contains list” operator.

Doesn’t List A:format as text is List B:format as text work? Using either the unique ID of the things in the list as the listed value or the field itself if it’s not a data type. Granted it doesn’t verify the list is the same order.


Great !
That’s a good idea :ok_hand:.

For the 2 texts to be comparable, we might need to sort items before comparing the “formatted as text” results. That is :

List A:sorted by unique id :formatted as text (each item’s unique id) is List B:sorted by unique id :formatted as text (each item’s unique id)

Thanks for the tip.

If anyone has a faster way, please don’t hesitate to share :wink:

1 Like

Is this back-end or front-end compare?

I’m excpecting a solution that works for both.

For front-end, I guess there are plugins for that. But the fact is that this is so fondamental that I’m surprised there’s stil no simple solution.

using :format as list only works when you also apply a sort
without sorting this would only check if the arrays are the exact same including order of elements. it could also provide false positives.

I like

List A contains List B AND List A’s count is List B’s Count

:point_up_2: the first part checks for matching elements and the second ensures the lists are the same length which ensures the first part accounts for all matching items

It’s consistent for both primitives and objects


@CharlesD I was only asking if front-end as that has more options and more WU to consider. Front-end may just be a hidden intersected group which is conditionally based on counts matching each other.

Generally speaking, @jared.gibb’s solution :point_up: is pretty simple (maybe isn’t classified as “clever”) and better than using any plugin and can be tinkered with for front-end usage for performance purposes.

1 Like

List A Intersects List B count equals List A count

Basically, does List A and List B intersect for all items in List A…

FYI: I don’t know if it works.

Hi @boston85719 . welcome :wink:

List A Intersects List B count equals List A count => Unfortunately, there are situations where this one will not work. if List B is larger than list A and list B contains list A, the result will be “true”. So, when using intersect, we need to make sure that the count of the intersection is same as the count of both A & B

1 Like

OK, So, to wrapup, so far, we have these 3 solutions :

1- Do It Yourself : You need to combine at least 2 operators, like here :

  • List A contains List B AND List A’s count is List B’s Count (from @jared.gibb )
  • (List A contains list B) AND (List B contains list A)

On top of that, you need to add one more condition to exclude empty lists (like count>0)

2- Plugins :
On nice plugin by @NoCodeDataArtisan referred to me Listopia [List Handler] Plugin | Bubble
To be tested out.

Possibly other plugins on the marketplace as well.

3- team => Need one simple operator.
We already have :

  • A union B or A+B: => merged with
  • A intersect with B
  • A minus list B
    We need A=B, and A <>B => simple operator without hassle

What about needing 2 operators that difficult?
Is cutting down 2 operators to 1 in the top 100 ideas you want Bubble to implement? Top 1,000?


It seems you don’t forsee the immense capabilities behind that. If bubble improves its way of handling list, you will see these operators coming in more server-side actions.
Have you seen any “intersect” in privacy rules handling? => No
When your business case requires filtering comparing list, you need to use things like “:filtered: advanced: this thing’s list intersect with …” which is front-end (Download size? + speed?). Or you need to find workarounds in the database structure + daisy chain (which you would’nt have done is you were calling data using sql or other languages)

So it’s not only about cutting down 2 to 1. It’s about making improvement in the roots, that will improve everything. That can definitely be in Top 100😜

1 Like

Hey @code-escapee ,
i see you’ve been asking questions and saying what was wrong, but haven’t suggested even one single solution so far :face_with_monocle:?

Privacy Rules won’t impact server side

I thought you were proposing a new operator. A new operator doesn’t impact any roots; it’s just stuck on top (many Bubble examples to demonstrate that). Making improvements in the roots I can get behind but that has to be the idea and shouldn’t be labeled as the addition of an operator.

I think the problem (2 operators) is the solution and also got behind @jared.gibb 's solution.

Front-end wise you have a point IF you don’t need the lists to be brought onto the page for other purposes (which why I was asking what use case you had in mind). However, if the lists are needed on the page, I actually would think that using a hidden RG with conditionals wouldn’t be a workaround as much as a feature for performance purposes.

1 Like

Sure, I’m in line with you on this :ok_hand:
On one hand, I think the operator does make sense. On the other, without knowing anything, I just found it surprising that it is not implemented to date, so I made the (probably wrong) asumption, that while working on it, they will surely optimize for WU consumption and this will trigger the question about the roots.

Anyway, thanks for your feedbacks :wink:

valid assumption but likely too optimistic :slight_smile:

1 Like