Do you think it would improve performance to divide multi-field CRUD Update Actions into a single CRUD Action per field being updated? (this would dramatically increase the number of CRUD actions within app, but narrow the scope of each one to a single input)
I have a Retool app that is multiple complex single-page forms. Each form has a Saleforce CRUD Action (Update), which syncs the data with the correct record in Salesforce. The Retool app has 12 forms, each with 5-15 inputs. And I currently have one SF CRUD update action per form.
For several fields, I use JS to transform the input into a Salesforce api friendly format, before triggering the CRUD update.
My thinking is that narrowing each CRUD update action to a single field would 1) allow me to provide "auto-save" type functionality; 2) would narrow the impact of a failure to a single field, which would also make it easier to troubleshoot.
I'm curious to hear what others have to say on this as well. It's certainly possible to implement a kind of 'auto-save' flow within Retool. I think the main cost would be the trips made to your server.
When those values are sent to your DB does your app need to wait for the response to finish before the user can continue editing? Or is it ok for them to immediately continue to the next field while the request happens in the background?
@Kabirdas it's ok for them to immediately continue to the next field. This is actually why I'm implementing
Got it, if you're using event handlers to fire your write queries you might want to make sure to properly debounce or throttle them, but you can have them running in the background. It's likely good to also pay attention to how often you're pulling data back into your app. You can also set forms and other components to not hoist their loading states so that you can load separate components individually:
It can also be good to keep the connections between components relatively shallow. For instance, if you have a query that fetches data, that data updates a single component that will typically be more performant than if that component goes on to update 3 other components and then each of those three updates another 5, etc.
There are more general performance guidelines here!
Does that help at all? Or are you asking something different here?