Hi Mike,

In taking a first look at what you have going on with your code, it looks like there might be a deprecated field renderer API in use that might be part of the undesirable behavior. https://docs.skuid.com/v11.1.6/en/release-notes.html#use-getrenderer-and-getfieldrenderer-instead-of-directly-accessing-properties This Doc outlines the change in behavior that I mentioned. If you could take a look and let me know if this helps that would be great!

Thanks,

Josh

Thanks, Josh. I came across the deprecation of fieldRenderers while trying to resolve this issue. You’ll notice in my posted javascript that I have commented that out and replaced it with getFieldRenderer. After looking at the Doc, I also tried returning the result of the API call, but with no impact on the display.

Hi Mike,

I took a second pass and found another deprecated API. It looks like the best practice is to not use skuid.model.updateData and instead use skuid.model.Model.update. There is a running list of features/API functions found in our documentation here: https://docs.skuid.com/latest/en/skuid/deprecated-features-api.html. My guess is that the framework of this is close to right, but a handful of changes have occurred between versions and likely the code needs a combing over to update to currently supported APIs. 

Thanks,

Josh

Please explain with an example. I used skuid.model.getModel(“otherUsers”), which returns the skuid.model.Model type. I believe I have only included one deprecated API in the script, and it is commented out. What am I missing?

Mike,

I was referring to this line: 

mymodel.updateData( function(result) { updateDone(result) });I think that there was a change to skuid.model.Model.update instead of using the .updateData API, additionally the document I shared covers any other use cases where behaviors have changed, which is why I shared that more as an FYI given the jump betweeen versions.Thanks,Josh

You are apparently referring to this:


But from https://docs.skuid.com/latest/en/skuid/api/skuid_model_model.html, we have:

So, is there a documentation problem? I am still very confused.

Hi Mike,

It seems like there is context being lost at some point in regards to the the current row. Could you try doing a do a console.log(‘result’) inside the updateDone, to see what the updateData result is returning? I am wondering if the data being returned is coming back different that what you expect?

My interpretation is that you are hoping to see the result come back 5 times and that each time the result would be a distinct record in the model you are re-querying, is that right?

Thanks,

Josh

updateData() returns an object that looks like this:


It has no material value to my code. In fact, in my ongoing testing I have removed the argument completely and get the same results behavior. The updateData() API returns a different object than save(), where one might test for result.totalsuccess.

And, yes, I want the results to come back from the updated model 5 times and have each individual result set rendered in the table cell.

The actual use case in simplified form is a structure where two SObjects are each children in a master-detail relationship with the same master SObject.

[Detail1] is a child to ---v

 +--- [Master]

[Detail2] is a child to ---^

The table on the page is populated from a model based on [Detail1], and one of the fields/columns in that table is a lookup to [Detail2] where the master reference value is the same.

I think we might do this with a LOOKUP() formula, except that the number of records in the Detail2 object would exceed the apex heap limit.

And, yes, the javascript method is terribly non-performant, but the data reported is valuable enough that the users are willing to wait for it.

Here is a more generic question: What is the expected behavior of this snippet?

console.log('start javascript'); var myModel = skuid.model.getModel("myModel"); var condition = myModel.getConditionByName("Id"); myModel.setCondition(condition, '005t0000000cfDhAAI'); myModel.updateData( function(result) { console.log('run the callback'); }); console.log('finish javascript'); return true;  

Will the console display:
start javascript
run the callback
finish javascript

or will the console display:
start javascript
finish javascript
run the callback

And if it is the latter, then what exactly is the purpose of the callback, and when exactly is it run?

Hey Mike, I’ll try to pop the stack as it were with these questions.

The expected result is as follows in nearly all scenarios, assuming the model does not error out during its load: 

start javascript
finish javascript
run the callback

The purpose of the callback is identical to the callback function in a .then block of a promise.

So: model.updateData(foo) would be identical in nearly all scenarios to model.updateData().then(foo)

The reason your snippets broke is a bit in the weeds so warning: 

WARNING - Nerdy Explanation Inbound

It seems before we actually make the request for your model data, we do other asynchronous operations now. So before we actually send any request “over the wire” with your updated condition value, the javascript event loop runs all other snippets for your renderers (which is a synchronous operation), so by the time the request is actually being sent over the network, the end result is 10+ identical requests all with the final condition value you updated things to. This is why all rows now get the same result.

It’s confusing I know. I was surprised when I saw it too. But I wouldn’t consider this a bug as much as a change in internal structure. The docs as written still hold true. Skuid is free to make the network request at any point during the Async function, and it is unreliable to assume when the formatting of the request will actually take place. Though admittedly it is very unfortunate that we’ve tripped you up the way we have.

However, I think there is a relatively straightforward way to fix this. And the fix will work in both Environments. 

Rather than having the snippet refer to a model that exists outside the snippet, and calling updateData on this model many times, create a new model on the spot with the characteristics you want. Call updateData on this model, and pulling the first row in this temporary model should have the data you are expecting.

Creating a skuid model with JavaScript can be seen in this Gist:  https://gist.github.com/zachelrath/4eef2eceaa2d56be9cf2 (lines 19-58)

Let me know if that was clear/unclear! Good Luck! 

P.S. I find your use of render snippets pretty cool

Thanks, Jackson. We’ll take a look at that. We may instead be able to create a server-side model on the “sibling” object (the one with the same master object) using the same fixed conditions as the primary model, We would then use the javascript to populate from the sibling model using a loop.

Yep if possible remove the need for multiple models! Much better!