Avoid setting states on the page but on Immediate Parent

Hi Community!

After using states for a long period of time I think I have come to the conclusion that setting states on the Page is not the best unless the immediate parent is the page. It does nothing but make future copy&paste fill your editor with errors. I now see setting states on the page as a recipe for disastrous future imports especially if you have a copy in case of a major bug.

After adopting “parent setting of states”, programming in Bubble has become much easier. I will recommend this as the best practise in Bubble. Members whats’ your say.



Indeed, it is much easier to put everything in one place and prevent unnecessary ‘debugging’.

1 Like

When I am building templates I use this technique since I want the users that purchase my template to be able to copy and paste it into their app with the least amount of errors. Otherwise, I add the majority of my custom states on the page itself to make them easier to find. Really, as long as they are in one place, that is the main point. Otherwise you will be looking all over the place to find it.

Hope that helps! :blush:

@j805 www.NoCodeMinute.com

For All Your No-Code Education Needs:

  • One-on-One Tutoring
  • eLearning Hub
  • Video Tutorials
  • No-Code Classes

Where and how the parent setting of states is used


Double edged sword. You should really be using reusable elements and not copying elements between pages where possible.

States at page level make it easier to see and edit a list of states in one place which is consistent throughout you app.

Otherwise set your state on the reusable element.

1 Like

I tend to put states at the page level (or at the level of a major container) for this reason. All of the needed states are in one place, and I know where to look if I have to come back to it after a while.

As indicated by the word parent I mean, what makes the logical sense to be called a parent but not just a grouping of elements.

NB: We do group element to assist in responsiveness at times but to encapsulate them in terms of logic.

When using a reusable element it will make sense, if we intend to pass parameters from the page is uses it{reusable element} , to set parameters on the Reusable element. However, if I have an hierachy inside the reusable element that it reaches a point where setting the state in the Reusable element itself is against my rule of the immediate parent, I usually prefer to use the immediate parent.

Note that when copy and pasting I may decide to copy a group from one reusable element to another reusable element. We can’t make everything reusable however. Reusable element tends to create a caveat in terms of where states can work. i.e you cannot set state to an element inside a reusable element when using it on a page. I think that lesson by itself should teach us manners/lesson when setting states in a page. For example when inside a reusable you are unable to set state to an element in the page where the reusable element will be used. In the same manner when using group we should tend to avoid setting states in the page where the group is used. In this way we give the “group” features similar to that of a reusable element.

i.e You may decide to make a group a reusable element. If you had initially set its state on the page then you have to redo everything due to bugs. If the Logical group had all states then turning it into a reusable element will not cause any bugs.

Though I agree setting the states in the page assist with consistency, setting states consistently on “immediate logical parent” then that may bring back the consistency we are looking for.