Dynamic handling of grid options, and document how to avoid watchers (ng-if, ng-class, ng-show etc)

[PaulL1]

When I started on the project I was surprised at how much hand-rolled code there was - click event handlers and the like. I generally followed the pattern, but without understanding why. I now understand that it is a deliberate strategy to avoid the performance impacts of large numbers of watches being fired on every digest cycle.

What would be great is to create some documentation for new contributors on:
a) Why we do this
b) The common patterns - so if you would have used an ng-show, you should instead do a compile or an append in the specific circumstance you need
c) Common gotchas, so if we hand roll then we need to have handlers for the common triggers - if you are simulating an ng-class, then you need to recalculate it whenever the data changes

I also wonder whether we could add some helper methods, or registration functions, or something (or perhaps we already have these and they're the column builders etc which should be getting reused). My thought here is that once we write down the patterns, we'd suddenly see that we have a bunch of items that we'd like to reevaluate whenever the data changes. Ideally we'd have a single data watch / registration thing that holds a list of registered functions that should be called when it observes a data change (or even that gets called centrally by anything that changes data, such as the edit feature).

If we got this right, we could simplify this whole process into a standard set of registrations that people use to get the equivalent of an ng-show, an ng-if etc. Basically it'd be a helper function that took a template and a condition, and some information about what events require a reevaluation of the condition. It would be like a custom angular - so it still takes the load off the developer, but the triggers for reevaluation are much more tailored than just "every digest cycle re-evaluate the whole thing".

[PaulL1]

In a sense #1792 might be an example of this - we don't want every bit of code creating it's own watch on the options, it'd be nice if we could have a pattern where we could just write an evaluation function that decides whether or not to show the footer, and register it to be dependent on the options. Whenever the options change the grid would automatically re-evaluate that function.

[PaulL1]

I needed something along these lines to provide dynamic column header classes - a method to notice that something had changed that might impact headers. I also applied this to cell class.

The logic behind it is to create a set of dataChangeCallbacks on the grid (refer registerDataChangeCallback and associated methods on the grid). These then get notified by the data watch (when rows are added or removed), the columnDefs watch (implying columnDefs have changed), and the edit end event. There is also an ability for a user to manually notify of data changes using the api.

Interested in a review of this approach and whether people think it looks good.