No chance the user pauses between entering characters.
I personally never use auto binding anyway.
Main idea of my approach for WU is the user modifying one field will not need to send all characters modifying all fields. However, there is the trigger of the workflow action which may eat up more WU.
No matter what it’s all basically a guessing game as to which approach is optimal as user actions are unknown. If you could force users to do things in the optimal way, you can definitely set up an operation and know it costs less than other approaches when in isolation. So, no idea if users will even pause long enough between characters on auto binding to make it more costly, nor any idea if user will update a single field so many times that it’s more costly.
If Bubble is considering done typing as the input is no longer focused that is great. If they do not consider whether the input is focused or not and a user types some characters and pauses before entering more characters then that’s not good and a single entry with a user pausing, entering, clearing and RE-entering then you’ll be charged more than you should.
Check with Bubble to see if the debounce is considering if the input is focused or not.
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.
This is incorrect (at least according to the published WU costs and my own testing)…
There is a total WU cost of 1.1 for modifying a ‘thing’… there is no separate cost for modifying a ‘field’.
So whether you make changes to a single field, or to a hundred fields, it’s still only a modification of a single ‘thing’, and therefore will cost the same in WUs. (1.1)
So it’s definitely better to use a single workflow to change many fields at once rather than multiple workflows changing individual fields.
And regarding autobinding…
In a regular text input the ‘modification’ won’t occur until the user either presses the enter key or clicks outside the input element.
However, beware of the Bubble Rich Text input - if you have ‘autosave’ turned on then the ‘modification’ will occur anytime there’s a pause of more than 2 seconds.
So, in terms of WU units, autobinding or saving individual fields in separate workflow will both cost a lot more than just a single workflow making multiple changes to a thing at once.
(I haven’t yet been able to ascertain exactly what it costs in WUs to change a field with autobinding, but I assume it’s no different from using a workflow)
So it’s definitely better to use a single workflow to change many fields at once rather than multiple workflows changing individual fields.
Yes I agree!
However, beware of the Bubble Rich Text input - if you have ‘autosave’ turned on then the ‘modification’ will occur anytime there’s a pause of more than 2 seconds.
I thought there was a cost per character that is being sent between the client and the server…from the pricing schedule there definitely is a per character cost on bringing data into the client, either from Bubble database or API provider and it states a cost per byte sent to or from an app via a inbound or outbound API.
I always thought Bubble treated the workflow actions to create/modify things as an outbound API call to Bubble server, similar to how the bulk wf API is used to perform the same bulk function we can run in the editor.
If there is no charge for number of characters or number of fields sent from the app to the database then that is great news, and would definitely be reason to just update everything at once, as well as try as much as possible on creating entries to have all fields available prior to creating.
This is good to know they do consider the focus of the input.
