We have several formula fields that we want to keep in sync with client side logic. We’ve placed these fields in field editors, tables, etc., however after updateRow is called on the field, the new value is not correctly reflected. From what I can tell, this only appears to occur when the SFDC field is read-only. I’m not certain if this might be by design, however as you’ll see below, certain situations will force the proper re-rendering of the data.
I’ve granted login access and created test pages called “SampleFormulaFieldDoesNotRerenderAfterUpdateRowRepro” & “SampleFormulaFieldDoesNotRerenderAfterUpdateRowWithSecondFieldUpdatedRepro.”
Steps to Prepare:
1) Create an SFDC object that contains a formula (e.g. quantity, price and extended price)
2) Create a object detail page
- condition on URL param ‘id’
- add a field editor (read with inline edit) with quantity, unitprice, extended price and a template for extended price
- add a table (read with inline edit) with same fields
- create custom snippet to calculate value for extendedprice and updaterow
- add action to run custom snippet on model update
Steps to Reproduce:
1) Preview page
2) Toggle Edit Mode on field editor for Unit Price and change value - Note none of the extended price fields change but the Unit Price of the table stays in sync
3) Toggle Unit Price back to read mode - Note that none of the extended price fields reflect the correct value
4) Toggle edit mode on field editor for Unit Price and change value - Note that the template version of the extended price fields change to reflect a different value but it is the value that was calculated from the result in #2 not in #4 (it’s basically one step behind). Also note that neither of the Extended price (non-template) fields have been updated.
5) Click the edit icon on the table row to toggle to edit mode for the row - Note that both extended price fields in the table now contain the correct value but the extended price fields in the field editor are incorrect with the extendedprice (non-template) field still containing the initial value
6) Change the unit price in the table row and toggle back to view mode - Note that both extended price fields in the table now contain the correct value but the extended price fields in the field editor are incorrect with extendedprice (non-template) field still contain the initial value
Now for the interesting part…
1) Add a new field to SFDC object (any text field is fine)
2) Update the snippet to include this field in addition to extended price in the updateRow call
3) repeat steps above - Note that the template field is properly kept in sync at all times. However, the extendedprice (non-template) is only updated in the table on edit/view mode toggle and the extendedprice (non-template) in the fieldeditor is never updated
Possible Workarounds
1) Use a template field and ensure that more than one field is included in the updateRow call (e.g. contain a fake field).
2) Use custom renderer (on a field that is not marked as read-only by SFDC). The challenge with this approach is that we use the calculated value in other areas and would incur the perf hit to recalculate values multiple times (some of our calcs are rather complicated). Not the worst thing in the world but not ideal. Being able to just use the formula field and have the client logic take over for what the server side SFDC logic typically would do would be preferred.
3) Explicitly call field.render() on any registered field for the field that was updated
Thoughts?
Thank you!
Read-Only field not rendering properly after update
+13+13Hello All -
Any guidance on the above? In short, when a field in a row gets updated, any template (or read-only instance) of that field should automatically re-render. I’ve granted login access, a test record for is TP-0001.
This is really starting to bite us, having to implement a lot of additional code to get fields to re-render when updateRow() is called to recalc values, etc. Thanks!
+8Hi Barry,
I cloned one of your pages and put some workarounds into the snippet. My favorite workaround for this issue is to just change the metadata for the field that is not getting updated from “editable” : false to “editable” : true.
+13Hey Ben -
Thanks! While you were doing that, I was inspecting further and found exactly what you describe. Because the field is not “creatable” or “editable” it doesn’t notifyEditors, etc. of the change.
The solution I put together was to add a “helper” field to the object (e.g. UIHelper__c) marked as numeric and just increment the value in there any time I make any other change. This is the “Temp” field solution from the sample page.
That said, I like your solution way better (I didn’t like mine to begin with lol).
Questions:
1) Is editing the metadata safe in this case? I’m editing metadata for other things during runtime but this one seems rather core and concerned about downstream impacts to other areas of skuid runtime code for formula fields. Since I’m batching up updates in a single updateRow call, I’d like to be able to edit the field metadata but just want to make sure there won’t be any downstream impacts.
2) Any chance the roadmap calls for a more declarative or built-in solution in the future?
Thanks again, this gets me past the hurdle, greatly appreciated!
+8- Yes, making a change to metadata like that could have a few implications. For example, if you change a formula field to “editable” : true and rerender that field, it will probably have a little pencil icon next to it when you hover over it. You can click that pencil, “edit” the field, and then save the model. Now, server-side Skuid will never trust anything that client-side Skuid has to say about metadata. So when that save is attempted, server-side Skuid will just throw it out and move on. If you wanted to be sure to avoid any side effects, you could immediately change the metadata back to how it was after the update data. That would be pretty similar to using the unsupported, internal _ignoreMetadata option.
2. There’s always a chance :). I would love to take a look at the code that is preventing the handlers from being notified and see if it is truly necessary at all. But I doubt that’s going to be a huge priority for us in the immediate future.
+13Hi Ben -
Makes sense regarding downstream. Fortunately, at least in my case, the fields are displayed in read-only templates so no concerns about pencil icon 🙂 Upon initial glance, it appears to just be a performance optimization - no need to re-render something that isn’t supposed to change. Would be great to see an option added somewhere decoratively to override the behavior. Having the perf optimization makes sense in most cases so not sure it would be worth the trade-off to lose it carte-blanche.
Thanks again for all your help!
+13Ben -
After some further testing things are looking good.
To (hopefully) close the loop on this, one thing I found is that since I’m supporting new row creation and updating formula fields on new rows, I also had to update createable to true. It appears that the notification check is based on whether or not the row id is new (createable vs. editable).
Thanks again!
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.