Forum Documentation Showcase Pricing Learn more

How could you create a list where the rows are mutually excluded when selecting a row?

We have a repeating group for which we wanted something quite common: To click on a row and have it being selected while the previous row was deselected, much like it happens to radio buttons, they are mutually exclusive.

Trial 1:
We tried to save a local element state, for each row, and we wanted to do two actions: first set the state to false to all rows and secondly to set the state to true for this particular row. The first action seems not to be able to be implemented by Bubble right now. You cannot have a “for each” functionality.
FAILED

Trial 2:
We tried to save the previous item as an element state in the entire list. So it would work like this: first set the state of the previous element to false, secondly set the state of current element to true and finally save the current element to be used next time. Here the issue is that when you create a state to a new element you can have types of number, string, boolean, Entity1, Entity2 etc. but you cannot have a type of “element” in order to save a group, a button, a text or any other element you would like. In other words saving an element inside a state is not supported.
FAILED

Trial 3:
We created a local state which was saved in the repeating group which is called current selection of type string. Then when the user clicks on a row the current selection gets the unique id from the row’s entity and saves it in this current selection. The row is instructed, with conditional formatting, that when its unique id is the same as the unique id saved in the local state of the repeating group then it should act accordingly.
SUCCESS


We will NOT suggest that trial1 or trial2 are good functionalities simple and generic to be integrated in Bubble but it would be good to be considered.
We will also note that from a developer experience perspective working with the unique id is not the first thing that comes into mind and whenever possible, if it can, it should be avoided.

Let us know what are your thoughts on the above and if there is a better generic solution that could be adopted.

I think your approach 3 is the right one indeed, but why using the unique id? You can set the local state to be of type of the thing you’re displaying, and then compare that without using id. We only expose id because sometimes users want to be able to generate a link that points to a specific thing, but that’s not something we want users to work with.

Yes you are correct.
Working with the type of the thing and comparing it using “is” is enough, no need for any unique ids
Thank you