Question about ListGrid.refreshData() and clientContext

[philip.haven@milliman.com]

Hello,

When using ListGrid.refreshData(), I'd like to pass clientContext, however refreshData doesn't take request properties the way fetchData does, so I'm not seeing a way to do this. I would usually put a reference to the grid in the clientContext so that I can take action on the grid in the callback of the fetch.

As a workaround, I saw the componentId property of dsRequest and see that I could use Canvas.getById() to retrieve a reference to the grid that way. However, the documentation recommends only using componentId for debugging purposes, so I wasn't sure if that was actually a good idea.

To summarize, is it safe to go ahead and use the componentId property of the dsRequest to get a reference to the grid in the refreshData callback? Or, do you have any other recommendations regarding passing context to the callback when using refreshData?

Thanks!

Philip

SmartClient Version: v12.0p_2018-08-11/LGPL

[Isomorphic]

We have great news for you, as it appears you don't know about a key feature of JavaScript, called lexical scoping, that makes keeping context really easy.

If you define a callback function, it can access the variables in the method around it, like so:

var someVariable;
myGrid.refreshData(function (dsResponse) {
     myGrid.doSomething(someVariable);
});

So you don't actually need to stuff a bunch of things into clientContext to preserve them. They are already accessible in your callback.

Note that if myGrid was only available as "this", you would need to assign it to some other variable name (just do "var theGrid = this;").

However, yes, the componentId could also be used to access the grid, and if there was some reason you really really needed to get something into clientContext, you could do so at the DataSource level via transformRequest. But lexical scoping is far easier.

[philip.haven@milliman.com]

Ah, ok. I was aware that this worked, but wasn't sure if it was a good practice... specifically, I was concerned about the possibility of a race condition changing the value of a variable if the same method was called multiple times. After some testing with artificial delays to simulate subsequent calls finishing before earlier calls, I see that in fact, each method call maintains its own scope. This will work great.

Appreciate the help and quick reply!

Philip