Repeating Groups with minimal WUs with vanilla Bubble - My best practices

[AutomationZilla.com]

Hi everyone,

As in other programming language, aim for simplicity in Bubble!

Here are some tips that have allowed me to develop much, much faster for internal tools in Bubble. These are principles that can be applied to a number of applications, I believe.

And with the new Bubble pricing, these repeating groups are not consuming much WU.

CRUD operations in one place
Managing reusable elements can quickly become a nightmare.

So, I put data display and modification in the same place using fields invisible borders and auto-binding.
No need to complicate things with separate forms for adding and modifying data and a page for displaying data: it’s best to put everything directly in the repeating groups with auto-binding.

Goodbye custom states, hello URL parameters
I usually put a lot of information in URLs. Some advantages:

• You can share a URL and get the same display from one computer to another.
• Custom states can become a nightmare when managing them between multiple reusable elements (you then have to update one reusable element, then pass the information to the other, etc.). When the information is in the URL, it is directly accessible.
• The “go to…” workflow doesn’t consume WU since it doesn’t completely refresh the page.

Thus, the conditions in the repeating group are URL parameters, which can be modified when filters are adjusted.

Display the detail of a cell without creating another reusable element
Again, to simplify, I usually put the details of an element directly in the repeating group. To do this, just:

• add an icon to view the details
• go to… workflow by putting the unique id as URL parameter
• filter the repeating group based on a URL parameter

All in all

Link to editor: Automationzillatemplate | Bubble Editor


Link to page online: Companies - AutomationZilla.com

Also see this gif.

Don't overcomplicate things, and this will enable you to save quite a bit of time.
Please note that these advices are more useful for internal tools, because they use native Bubble functionalities without specific design widgets.

Please tell me if you have other advices to simplify repeating groups and data management for internal tools.
And let me know if you have questions!!

[mghatiya]

Are you sure “auto bind” is a good practice in new pricing model?

[AutomationZilla.com]

@josh gave an answer here, and yes auto-binding seems to stay a good practice in new pricing model

Question asked:

How does the WU system affect auto-binding? Since each keystroke attempts to save data to the server, will it be billed per keystroke per field?

Response:

We de-bounce auto-binding, meaning that we wait for the user to finish typing before updating the server.

An Update to Workload, Plus More Transparent Calculations

Hi all, following up with a few quick updates and some answers to a few of the questions: The pie chart now shows both % and absolute WU. Thanks to the couple people who made that suggestion! You can see WU usage by your workflows in the Logs tab now Re: the reports of “Deleted” pages showing up in the pie chart, as people on this thread correctly surmised, that was coming from visits (probably by crawlers or script kiddies) to pages that didn’t actually exist. We can confirm that we do not us…

So it counts as an item modified in the database (once, as other methods).

Another method could include a “Validate changes” button instead of auto-binding (if your users usually make a lot of changes on an item every time they modify it). But in my experience, for internal tools, the users usually modify one/two field(s) only when they work on something.

[mghatiya]

When there is a good number of fields in the screen to change, auto bind would cause an excessive load surely.

However, in the cases where there are lists as part of data types, there we can’t even have save button as (unless we use plugins to loop through repeating group and save). So there auto bind kind of becomes mandatory.

[mack2580]

This might be helpful for me I need a new way to do pcpartpicker like filtering without destroying my wfu this with maybe list shifter processing

[ihsanzainal84]

Auto-binding in theory works okay but in practice most users will write, pause, write, pause. Each pause will update your DB.

Essentially what you want to do is reduce the number of calls to the DB. Load stuff client side and make it static somewhere (state, group etc). Then render/process data from there.

All you have to do to reduce real-time data is to not spam Search For operators everywhere.

[AutomationZilla.com]

@mghatiya in the repeating group that I provide here, there are about 15 items loaded on page load. The rest is loaded when the user scrolls the page, so you have about 45 auto-binding fields to load, so it is not excessive.

And I’ve built 2 custom ERPs with Bubble (a bunch of different custom internal tools companies needed), and the repeating groups take less than 1 second to load, considering that each one contains about 40 to 70 total auto-binding fields when loaded.

So my experience is that auto-binding fields are really quick to load (with the configuration I’ve presented above at least), and they are very good for the user experience for internal tools (much more than having to click on a “Save” button).

@mghatiya how do you deal with it personally?

[AutomationZilla.com]

What do you mean by pcpartpicker and how do you filter currently?

[AutomationZilla.com]

@ihsanzainal84 I see your point to not spam Search For operators. But then, is it still a good user experience? As the users won’t see the data as it is updated…

Concerning the point on “most users will write, pause, write, pause”, my experience on one of the custom ERP that I built is that the auto-binding WU represents about 2-3% of all WU. That’s maybe because it’s an internal tool, but for the moment it’s okay in terms of price.

[ihsanzainal84]

If it’s a part of your UX I don’t consider it as spamming. I’m very sure there are alot of Bubble apps out there using real-time search unnecessarily as it wasn’t really something to worry about until this new age of WU.

I personally have done that in my own apps and honestly, i find that when i broke down my UX, there were many parts of my app that didn’t need real-time data.

[mghatiya]

It is not so much about auto bind being slow or fast. It is reasonably fast, but doing a DB call for each field will eat up a lot of WUs.

I have a save button for my forms usually so that people can click that button when they are done editing the fields they want to edit. I have auto bind only in cases where I present a table like view and want to give inline editing to people. But I mostly avoid that, and would especially do so now with new approach on WUs.

In fact in many cases people prefer save button themselves as they like to have a look at what all have they changed before submitting. Also sometimes they do experimental changes in dropdowns etc. And if we have many fields and have auto bind, then it gives a bit jerky experience to users if they have to keep moving from one field to another.

[AutomationZilla.com]

@ihsanzainal84 yes sure this new age of WU will change things and more “not-real-time” repeating groups should be created.
I really depends on the quantity of Search For WU consumed on data types.

[AutomationZilla.com]

Yes indeed with the new approach on WUs, we should be more careful of the consumption of modification of data.

For the user experience part, I think users get used to it for internal tools.

[boston85719]

When using the filter operator after a search and the filter operator constraint changes, like you have for URL parameter value in Name, does the search get run again, or does Bubble just do the filtering on the original search and ignores the change in URL parameter used for the filter operators constraint as that constraint is not on the search itself?

[boston85719]

@mghatiya

However, in the cases where there are lists as part of data types, there we can’t even have save button as (unless we use plugins to loop through repeating group and save). So there auto bind kind of becomes mandatory.

You could make a reusable element that is inside of the repeating group cell and have the save button in the reusable element which will save the changes to the custom data type you put onto the reusable element, which is the same as the custom data type of the repeating group.

[boston85719]

I do similar. In apps and templates of mine for a user profile admin panel I make it so each field on their profile needs to be updated individually. On the right side of page is a list of the fields for quick click to edit a particular field - it also shows a check mark or red x if the field is filled in or not. One left side of page is the profile details presented, with icons to click to edit the field.

With this, the user data is only modified after they click save, and they can go back without saving if they want as well.

Now that Workload units is a thing, it makes much more sense to do this rather than allowing a user to modify all fields and click a single save button, because as a developer you have no idea which fields they might have modified, so would need to change all even if they were not changed by referencing the inputs value, and now that will eat up a lot of unnecessary workload units.

[AutomationZilla.com]

@boston85719 so you’re making changes to things one field at a time? How is that different from auto-binding (in terms of WU)?

[AutomationZilla.com]

@boston85719 yes Bubble does the filtering client-side if you use the “filtered” operator, that’s what I have done on the repeating group. It’s very quick as the filter is just based on unique id.

[mghatiya]

@boston85719

You could make a reusable element that is inside of the repeating group cell and have the save button in the reusable element

Yes, I can do that. But then there will be so many save buttons. So for example there is a form where user’s profile details are edited and one of the fields is a list of known languages with their fluency etc. Now, while showing that list in a repeating group if we make a save button for each list item, it becomes too many clicks for users to save. And I have also seen that people forget to click on those buttons as there is a common save button for all other things.

So in such situations I end up doing an auto-bind in the repeating group lists if I want to keep only one save button for rest of the fields. Yes it causes bit of inconsistency as some fields are getting auto saved and some fields on save button, but that I feel is lesser of the evils.

[mghatiya]

@AutomationZilla.com

@boston85719 so you’re making changes to things one field at a time? How is that different from auto-binding (in terms of WU)?

I have same question. I don’t think I understood. You have save button for each field or one common save for all? If save button (or equivalent icon etc) for each, then it would cause more WUs as well if person changes more fields? I guess it might depend on the context as to whether you expect users to make less changes or more changes at a time.