Race condition: onRegisterApi

[smajl]

E.g. http://ui-grid.info/docs/#/tutorial/308_external_filtering is not working because gridApi.core is not ready when onRegisterApi callback executes.

The example uses $interval to overcome this (like rly?), but you need to set the delay to 500ms or so to make it work.

Using $interval is madness, so does anyone have some proper solution or is it planned to sync onRegisterApi callback with other critical parts of the module? Thanks.

[PaulL1]

It's a known, and it's a crappy solution, yes. #1641 is tracking it.

I think the issue is that all the registration is asynch, so there's no predictability about when it's complete. The features do their own registration, and the core doesn't know whether the features are there or not - so doesn't know when the registration is complete.

It's not an unsolveable problem, but it's not an easy one to resolve. It really shouldn't take 500ms, but it probably depends what else is occurring in your code.

[smajl]

Seems like a major flaw to me. OK, so is there any particular plan to resolve this? If no, lets brainstorm a bit... :D

1. Quick hack

Hmm, how many core events are there? Only these four? filterChanged, renderingComplete, rowsVisibleChanged, sortChanged? Or some more?

What about initializing core with four already predefined promises? filterChangedReady, renderingCompleteReady, rowsVisibleChangedReady, sortChangedReady?

Then doing something like:

onRegisterApi: function (gridApi) {
  gridApi.core.filterChangedReady.then(function () {
    gridApi.core.on.filterChanged($scope, function() {
      ...
    });
    ...

Features would then resolve these promises and everything will be in sync.

---

2. Something more "clever"

Make it an universal system? Let's say that it would be features responsibility to resolve promises with the same name in GridApi (or create them too, if they aren't already there) and programmers responsibility to create or check if these promises are ready.

So on my side:

onRegisterApi: function (gridApi) {
  // gridApi.ready could be a place to check and create these promises?
  gridApi.ready.core.filterChanged = gridApi.ready.core.filterChanged || $q.defer();
  gridApi.ready.core.filterChanged.promise.then(function () {
    gridApi.core.on.filterChanged($scope, function() {
      ...
    });
    ...

On UI Grid side:

GridApi.prototype.registerEvent = function (featureName, eventName) {
  ...
  var deferredReg = self.ready[featureName][eventName] = self.ready[featureName][eventName] || $q.defer();
  ...
  defferedReg.resolve();
};

Note: this is a very rough idea..

[PaulL1]

I think there are two different things here:

• the core api being registered
• the features being registered

Ideally onRegisterApi would fire after both have happened.

For the core api, it should be possible to work out exactly what order they register in and make sure they are registered before onRegisterApi. Worst case we could move the registering into the api itself so that it was always there and synchronous (I already did this for the renderingComplete event).

For the features, the problem is that the core doesn't know whether they're included or not. So the fact that we don't have a register from a feature may be because it's slow starting up, or may be because the user hasn't enabled it. I'm not sure that your approach resolves that dilemma.

I think your suggestion could reduce the window where things aren't registered, as the feature could immediately upon startup log a promise, then the grid would wait until that promise was resolved. The problem with that solution is that the pattern for most features is that the absolute first thing they do is initialize, and initialize calls the api registration. So at the point where we could create this promise, we could just register. The promise wouldn't make us any better off.

Overall I think we need to have a bit of a discussion about the sequence of events to initially render the grid, and see whether we can:

a) strip it down to it's basics - see if there's anything going on that doesn't need to go on
b) make it more deterministic, perhaps through use of promises and explicit sequencing
c) include feature registration in that process - so make sure we've given time for features to register before we push out the onRegisterApi call

[PaulL1]

OK, I've found a partial solution. The problem with much of it was that I was registering the methods from within the objects themselves. The trouble is that some of those objects (e.g. gridRow) only get instantiated once data turns up. So that was meaning the registration was delayed.

I've now pushed much of the registration into the api itself (for the core methods). This means they are there immediately. The exception is the grid menu, which lives inside an ng-if, and so it needs a digest cycle before it exists to register against. But it means a $interval of 0 now works, which is more acceptable.

I think the features probably have similar behaviour, i.e. they're either there immediately or might need a $interval 0.

[AnirudhaGohokar]

Thanks Paul. I was using ng-if over data grid.Setting timeout to 0 has solved the issue.

$interval(function () { $scope.gridApi.core.notifyDataChange(uiGridConstants.dataChange.COLUMN); }, 0);

[seasagar]

can onRegisterApi function capture event occur inside cellTemplate?
O have a cell template with text field and I want to read old value and new value using "beforeCellEdit" and "afterCellEdit" event.
I believe onRegisterApi does not work with template(header template or cell template)