I am setting the value of several Text Input fields in JS. Here is my code:
var data = qrySources.data
var rowID = sourceRowID.value - 1
selState.setValue(data.state[rowID])
txtSourceName.setValue(data.sourcename[rowID])
txtInfoLink.setValue(data.infolink[rowID])
txtDownLink.setValue(data.downloadlink[rowID])
txtAcquisitionInstr.setValue(data.acquisitioninstructions[rowID])
txtProcessingInstr.setValue(data.processinginstructions[rowID])
txtDataFormat.setValue(data.dataformat[rowID])
txtVWRScriptName.setValue(data.vwr_script_name[rowID])
txtContactName.setValue(data.contactname[rowID])
txtContactAddress.setValue(data.contactaddress[rowID])
txtContactPhone.setValue(data.contactphone[rowID])
txtContactEmail.setValue(data.contactemail[rowID])
txtAgency.setValue(data.agency[rowID])
chkScriptAutomated.setValue(data.scriptautomated[rowID])
chkSkip.setValue(data.skip[rowID])
chkHistorical.setValue(data.historical[rowID])
chkEasyManual.setValue(data.easymanual[rowID])
chkHighPriority.setValue(data.highpriority[rowID])
It takes between 1/2 and 3/4 second to set these values on the form. I can see them change from the top of the form to the bottom. I would expect it to take milliseconds to do. My users will “scroll” through the records in a form (next/prev buttons) rather than a table and the delay will quickly be noticed.
I also tested to see if it was a browser issue by opening the project in Firefox. I also did test in Preview mode. It just seems to take a little while to fil everything in on the page.
Yeah, .setValue() is actually a somewhat expensive method performance-wise. It is being sent from the sandboxed JS iframe to your app through a JS API, and there’s some room for improvement there on our end.
Is there any reason why you wouldn’t want to reference these values inside of those component’s default value settings? I.E. inside of the textSourceName component setting the default value to {{tblSource.selectRow.data.sourcename}}. That should update each time the selected row is changed and perform much better!
Actually, that is what I was doing originally. Ben told me about the setValue() option in another post and after some internal debate decided it was best to centrally locate all of the form state logic.
But after the performance issue was noted I rolled my changes back (using history) to setting the default value and the performance did not improve.
However, I did not not notice a performance issue before changing to setValue(), so I don’t know. If you are certain that using default value will perform a lot better, I may manually refactor that form back to it and see what happens.
If the form is populating it’s default values from a single state, they would all update at the exact same time and should perform better. I know if you take this to the extreme and run a few hundred individual .setValue()'s vs a single .setValue() on a temporary state that is an object including all of the individual key values, the single action will perform much much better.
After rolling back those changes, what is the workflow that the default values get populated in? You still see them roll in top -> bottom? If you open the browser console you will see a log of any JS “API” methods that are being run, I’m curious if that might still be part of the JS query?
I copied the project, moved all of the value setting code into the Default Value entry. No change. I then started ripping out all of the subforms, subtables and other pieces that were not part of the form in question checking performance at each stage. It is now as barebones as it can get and it still has the same performance issue.
The values are all populated from the qyrSources.data object. For instance my Name field is getting its default value using {{qrySources.data.sourcename[sourceRowID.value - 1]}}. The sourceRowID is a temp state var which is my row pointer. Not sure where that stands re your comments about state.
The workflow is:
qrySources gets run against my Postgres database over on Azure.
That triggers SourceSuccess js query which sets sourceRowID to 0 which triggers the form elements to get their initial default values.
I click btnSourcesNext or btnSourcesPrev which increments/decrements sourceRowID which triggers the form elements to get their new default values.
Clicking btnSourcesNext also triggers the js_SourceTable_OnClick query which selects the table’s to the matching row (using the selectRow() function)
I see my apps performing very poorly randomly with set value. I haven't cleaned the inside of my computer for a few years. I'm thinking the CPU performance getting pulled back to stop a burnout maybe part of my problem. Haha!! I'm not sure it should take so much effort though, to write to a temp state? While working on apps I can sometimes hear my fans revving up and down wildly. Again, my bad for not clean it out but still question if the apps are really doing enough work to justify this seemingly random thirst for power!
I also use a temp state as a placeholder for editing a record. I usually clone the data into two states. One for the original data and one for the data that is being changed by the form inputs. I use JSON.stringify() to compare the old and new states and then use that to drive the disable submit on the form. Makes it nice and clear for the user to see that the form has not changed yet. Or did change but has been put back to it original state when the see the submit disable again.
Hey Shawn! Oh no, I'm sorry to hear your apps are setting your fans off About how much data are you comparing? And has this slowdown been a recent development?
About how much data are you comparing? And has this slowdown been a recent development?