Do Not Overuse Parent Groups Thing

Tips
1

I made this mistake when I first got started. For the past 5 years now, I’ve been avoiding the overuse/abuse of the ‘parent groups’ thing to pass values down to other child elements when it is for the most part completely unnecessary now.

If you are working on a page set to content type you can always just reference the pages ‘current thing’ or if on a reusable element that you set as a type of content reference the reusable elements ‘thing’ instead of the ‘parent group’s thing’.

Why have I not been overusing the ‘parent groups’ thing to pass down values to child elements? Because, when I want to repurpose elements or complete components and I’m changing the type of data, I do not need to go through the process of dealing with all the issues of the content type not matching. Like the below screen shot.

Screen Shot 2024-09-16 at 5.05.27 PM

Just because Bubble puts the ‘parent groups thing’ as the first datasource, doesn’t mean it is the best or most appropriate reference…there was a time when it was, but that time has passed.

Another reason, is that with reusable elements finally becoming more powerful through use of properties, it is even easier to build reusable elements that will be used for more than one data type. In this situation, I’m using one reusable element as the Create and Edit functions for two different data types. I put two groups onto the reusable to be the ‘selected thing’ for their respective data types (I can not use properties for this as we can not use an action to set a property), and for me personally it is easier to reference a group than a custom state (various reasons).

Screen Shot 2024-09-16 at 5.10.56 PM
Screen Shot 2024-09-16 at 5.11.14 PM
Screen Shot 2024-09-16 at 5.11.21 PM

Additional tip

Naming conventions hugely important. If I have a data field of type text with field label of ‘name’ on one data type as well as one another data type, I can easily swap out the content on my group that is the ‘selected thing’ and all values are ready to go (so long as the field types are the same and of same label).

11 Likes
2

This is true for custom states too

3

Hey @boston85719 - interesting tip - although I think you’re going to run into more headaches with maintenance trying to change datasources (of the same type) to these sub groups in future.

If you need to change the ‘type’ of multiple groups in the subgroup, you can select them all and do so.

1 Like
4

I think a couple of key points were missed from the post:

  1. I’ve been doing this for years - so no issues so far.
  2. I am not changing datasources of sub groups, which is basically the main point of the post.
  3. Keeping your data fields names consistent between different data types when appropriate means no other change than just the main datasource in the single area the datasource is.

Yes, as this is a possibility now, as Bubble released that feature within the past 12 months or less maybe, that feature still makes it harder than my approach to make the changes. Here is why, in my approach, keep in mind, the sub groups do not have a data type, only the elements like an input or a text have the data type set and the data source is a reference to either the page content type, the reusable content type or a group that has a content type, so all I would need to do is change the page content type or the reusable or the group of references content type, making it just one single click.

If I were to have the sub groups with a content type and use the ‘parent groups thing’ approach, as the tip recommends for people to stop abusing/overusing, I would still need to click into every sub group to select it, and know which ones do or do not have a type set on them, and after having clicked into all, use the new function to update all. Still, this new function makes it easier than it was in the past, but is still more clicks and more time than what my tip is expressing as a better approach to referencing data sources.

I recommend giving it a try, you might come to love it.

1 Like
5

Yup :+1:

1 Like
6

You can indirectly by using a custom state linked to the property, and then setting the custom state.

1 Like
7

Yes, I know this. I mainly use Properties for things that will not change and custom states for things that will change. I try as much as possible to avoid redundancies, and in my mind, needing a custom state to change a property is a redundancy. So, it comes down to why not just use a custom state then, as there is no need to set up a custom state and a property, just so that we can change the property value.

I use properties for things that won’t change, and also need to be inherited from other elements the reusable may be placed on. For example, on my page I have a plugin element called page height, which exposes the height of the page, and to avoid redundancy, I do not place that plugin element on the page and in every reusable element that will need the value, instead, I put the plugin element on the page and set up a property on the reusable element and set the property value from the page.

1 Like
8

I can’t seem to find much use for these properties. For example, I have a reusable element popup, but if I go into the reusable element and look at the data sources, only the elements in the reusable element itself are available as sources. I can’t see elements on the page itself.

9

That is why we have properties. Can use property as datasource in the reusable element. Then when you place the reusable element on page, set property data source to the source on page.

10

reference ‘popup’s property’ as if the property were a state - a property is just that, a property of an element.

11

Sometimes (a lot of times), I get confused about some things in bubble.

But, if I have a SPA and all reusable groups, I can’t set any group to page source because I have different groups using different data types?

If I set the page to one data type then all my groups would have to be that data type?

Am I correct in thinking this won’t work on single page apps…or am I missing something?

12

Pass it down through properties

You probably wouldn’t have this in an SPA anyway, just use a URL parameter

2 Likes
13

Thanks George.

I have about 30 reusable groups…which I know is small time compared to some of the discussions I’ve seen on the forum.

I set each group’s data source and only use URL parameters.

I just thought maybe I was missing something about setting the page source.

Thanks for your reply.

14

In an SPA, your page should not have a content type set.

No, that is kind of what the post is trying to help people understand, that just because you have a datasource for a group, not every child group needs to have the same data source, so bringing this to the sense of page content type or reusable content type, any groups you place on the page or the reusable can have their own content type that is different.

Yes, in the post I state that it is best to reference either the page content type, the reusable content type but I also mention that at times I have groups that are used as the reference for the data source. The main concept is that to continuously just pass the value down from one container to the next using the ‘parent groups’ thing is not best practice as there are other sources, mostly from the context of having multiple child groups that do not need the data since they do not have an immediate child element that is displaying the data. So think about a situation in which there are 4 groups that are necessary for getting the right design layout, and it is in the 4th group that a child element of a text element needs to display a value…group 1, 2, 3 and 4 do not need to have a data type set and do not need to have the value passed down by referencing parent groups thing because in that text element you can very easily use the ‘current page thing’ or ‘reusable thing’ or ‘reusable property’ or ‘reference groups thing’, making such that when you want to copy and repurpose those elements in the same app or another app, you will not need to alter group 1, 2, 3, and 4 content type and would most likely (if the naming culture expressed as an additional tipe in the post is also followed) only need to change either page content type, reusable, or reference groups content type.

You do not necessarily need to use a URL parameter, and those too should not be overused. Depending on the app setup and UX as well as features, a URL parameter may not be necessary at all, and should not be considered as a blanket fix/reference of data for all situations. I use a URL parameter as a datasource in the past for reusables to more easily communicate with the page, and this is not necessary now due to properties, but I do have features I implement into apps, like showing a single selected value in a repeating group and I use a URL parameter for that single selected value to be in the URL for the purposes of having a URL that can be shared or emailed so that somebody can follow that link and see the exact entry of importance. I use URL parameters for navigation, especially for a dashboard or SPA to change views (but if my SPA needs SEO, I use URL paths instead). Most of the time for a dashboard or SPA, my group has a content type set to a option set, with a condition to be visible only when the URL parameter value is the parent groups option, and that option set is used for the navigation menu. Inside of that container group with a content type of the option set value is most likely a reusable element that has all the elements/features/functions necessary for that ‘view’.

Don’t overuse reusable elements either. Recently I started to rebuild an app previously started by other developers who overused the reusable elements. They had buttons as a reusable element when it should have been just a button on the actual reusable element that required the button. Basically they had about 10 reusable elements that I had to pick apart and turn into the one reusable element necessary. A lot of times people pick up a new trick or have a unique approach to something and they begin to overuse it and apply it to situations where it is unnecessary and makes maintaining/debugging an app more complicated and tedious than necessary.

2 Likes
15

Probably to have a loading state or other non-native button features?

You can’t just throw them in and expect to have a good app, but in apps I’ve audited, apps with many REs tend to be much better built than apps with few…

As long as you use them judiciously, REs will improve product maintainability, and if they don’t, they’re probably being used wrong.

1 Like
16

I’m not sure what you mean by a loading state or other non-native button features…in my understanding a loading state can be easily achieved via conditions on the button, but I’m not sure what types of non-native button features you would be referring to.

I couldn’t say that apps with few reusables are not as well built as apps with more reusables. Everything as you said needs to be judiciously.

True, basically the point of not overusing them as overusing them can cause the app to be less easy to maintain and debug.

17

Thanks.

I try not to overuse reusable elements in micro detail.

My groups are all reusable and I use URL parameters so people can share links.

Also, I mainly try and use styles so everything can be quickly changed according to screen size without going through the app and changing everything one at a time. It seems to me like styles are also another easy form of reusable elements in the sense of quick styling.

I started my app as an SPA simply because not only is it quicker, but if I were to ever change it to a native app it would already be set up.

1 Like
18

With the addition of custom breakpoints, styles are even more powerful in the sense of being another form of reusable element.

I first started to build using reusable elements for specific features/functions to avoid the editor crashing. Then it became clear to me how the ‘go to page’ action when on the same page is much quicker and a better UX.

I’d recommend continuing that approach. Generally speaking, if something is only used in one place of the app, it should not be a reusable element, unless of course it is an entire feature set that will be placed onto a dashboard or SPA.

1 Like
19

I realize most apps are probably more complicated than mine…

but I’m still learning.

A few days ago I had a small panic attack when I viewed my app on a wide desktop. I had built my app on my laptop. The spacing was all out of wack.

I ended up adding a group to the index page I called ‘group margins’ so I could easily adjust it across all browser sizes in one place.

I’m still a little confused on a SPA when using a URL parameter what the difference, or gain is when you click go to index page, or go to same page. I’ve been trying to figure out if this affects page load when it comes to WUs.

Anyway, thanks for your feedback.

I always get a ton of good tips from you.

20

You can create a style for that group and use conditions with custom breakpoints to dictate the padding/margin…my preference is padding.

I assume you are using the go to page action to navigate. I do not think there is a difference between explicitly indicating which page or using the ‘same page’ feature in relation to WUs on page load.

So long as you are using the go to page action and the user is being navigated to the page they are on via that go to page action, there is not an additional WU charge for page load of 0.15 WUs, but your ‘when page is loaded’ triggers will fire. I have confirmed this with Bubble support in the past.

Additionally, you should not be incurring any WUs for data searches as the page is not really being loaded again, and so the data is not needing to be re-fetched. I first came to understand this years back when I noticed that custom state values were not lost when I used the go to page action instead of the link or other navigation approaches. It was a focal point of one lesson out of 8 when I lead Bubble hosted Bootcamps.

1 Like