Parent's group 'thing' or Current page's 'thing'

I’ve been told by someone with more experience than me that one of the ways to reduce the burden on the server and improve load speeds is to use more of Parent’s group ‘thing’ or Current page’s ‘thing’, so the the app loads the data once without having to do it at each instance as is the case now. I currently have multiple ‘do a search for’ on a single page to load information from the same database for lots of text fields, and therefore I’m trying to opt for using the parent or group’s thing - assuming of course there’s actually a benefit in using the above expressions.

The issue is that I cannot see the option of ‘Parent’s group XXX’ in the dropdown when selecting the option to create a new thing whilst in the workflow. I’ve even started with a new, blank page within the app and still can’t see it. I thinking there may have been an element or group that wasn’t configured with a type correctly - but after check the page and the only group on the page, they’ve all got the ‘type’ of data I want to display within them.

So now I have two questions:

  1. If I’ve got a barebones page with a group, a text field, a rich text editor and save button, what do I need to check to ensure that my page/elements are not disabling this feature of seeing the ‘parent’s group ‘thing’’?

  2. I can’t see the “parent group XXX” option (as explained above), but I can see the “current page’s XXX”. Based on the names here, I assume one fetches data for the group’s data type, and the other from the page’s data type. If this is the only difference could potentially use the latter option (as its readily available to me) to achieve the same goal? However, am I right in assuming that in future I need to be sure that there aren’t any elements which might need to pull data from a group and not the page? I’d appreciate if I can get some clarity between the two if my understanding is incorrect.

Any guidance and insight into the above would be very helpful and appreciated as this is a major blocker for me at the moment and seems like it may impact the overall architecture of the app.

You should always be able to refer to the parent group’s thing (assuming the parent group has a thing), so I’m not sure why you’re not able to see it - maybe share some screenshots of you page setup if you want some help with it…

It’s definitely better to not keep repeating the same search multiple times on the page, although I’m not sure it matters much from a performance perspective (I’ve never tested it to be honest, maybe someone else has)…

As far as I understand it (as as per the Bubble manual), if a page has the same search in more than one place, Bubble will automatically combine them to run the query just once - so it shouldn’t make any difference in that regard.

But just from a development and maintenance point of view - if you’re using lots of the same searches on the page, if you ever need to change it you’ll have to find them all and repeat the same changes everywhere

So it’s much simpler to have a top level datasource (whether it’s the pages thing, if it has one, or any other element on the page) and then just refer to that when you need the data.

Thanks for the reply.

I think I may have figured out why it wasn’t showing when I was in the workflow and trying to ‘create a thing’. It seems that for the parent group option to appear, the elements themselves need to be nested within at least two groups, and the save buttons on which this workflow would be triggered needs to be nested within at least one of the groups.

For example, I started my test page like this:

Page

Group 1

Text box
Rich text editor

And the save button was just on the page outside of the group.

The solution for is:

Page

Group 1

Group 2

Text box
Rich text editor
Save button

It may well work without the additional group, and just the save button within the group somewhere, but I haven’t explored it with that much depth yet, but the above solved the issue.

It’s one of those things that isn’t written anywhere (and probably should be) but makes sense once the solution is discovered as the save button needs to be part of the data being pulled. Originally I had my save button over off on a floating group to the side so it always moved with the page. However, it may still work if I nest the button in a group of its own and give that group a data type (along with the floating group).

Hopefully the above might help someone else in future with this issue.

There’s no need for additional nested groups - as long as the element’s parent group has a thing, you can refer to the parent group’s thing in any workflow.

It looks like you’re right about not having the additional group, I’ve just tried deleting it and it appears to retain the ‘parent group’s’ expression in the workflow for the save button. However, as soon as the save button is removed from the remaining group, the expression turns red, indicating that the button needs to be part of that parent group’s thing, which makes sense. The option of choosing the page’s data type is present if the user didn’t want to nest the save button within the group.