General "Best Practice" question in this case

Imagine you have a yes/no field (on a type “Claims”) called “Approved?”, and keeping the status as “approved” requires all authorized approver’s to be included in the “approved by” field.

Now, adding and removing approver’s to the “approved by” field are depended on a host of conditions, which are being changed all over the app, for example if an approver decided to re-verify a claim, his name is being removed.

How would you have the “Approved?” field dynamically change based on the “Approved by” field without having to change this whenever an action might have implications on the “Approved by” field?

There is an option to have on every page a “Do whenever condition is true” event, with an action to change the “Approved?” field, but as i understand this will slow the app down significantly, since bubble will keep looking for this “Approved by” list and recalculating.

There is another option to NOT have the “Approved?” field altogether, and use a condition whenever you want to show data based on “Approved or not”, which i think is really not very neat and time consuming.

Why not have a special event, called “whenever a DB field changes”, to be used on API page without any page trigger?, so whenever a thing’s field’s value changes, another field’s value of the same thing changes too

1 Like

We’re running into similar challenges with our app and it’d be great if Bubble provided a better solution for larger apps that re-use database fields across many pages and often re-run similar logic on many pages.

So far, we add the same logic in each instance we’re changing something. This is tedius to set-up and can be time-consuming to maintain / ensure it works identically in all places. Definitely not DRY (Do Not Repeat Yourself), which is a coding best practice.

We’ve considered adding a workflow in the API and then passing in data in each workflow that changes the database field to check it that way. Seems like it’d be easier to maintain and update this way. Probably a better practice than what we’re doing. But, still leaves a lot to be desired.

Anyone else have a better solution?

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.