Open Telem opened 8 years ago
Further investigation shows that this is happening only when bind-template-url is used : it seems angular loads up the template and compiles its directives, and when tastyPagination's link function replaces the element with the new template, the elements created for the original template are not properly removed (e.g. watch functions for the ng-repeat from the original template still get called).
A limited workaround for those interested :
angular
.module('myApp')
.config(setTastyConfig);
/** @ngInject */
function setTastyConfig(tableConfig) {
tableConfig.templateUrl = 'path/to/my/pagination/template.html';
}
I would prefer not to modify the tableConfig constant, but using bind-theme would not have any effect (despite what the documentation implies).
Sorry I won't have enough time to spend in providing a backward-compatible PR. There are a fair number of options to choose from though (http://stackoverflow.com/questions/21835471/angular-js-directive-dynamic-templateurl)
Thanks for the workaround.
Pages containing a tasty pagination leave a pretty big trace in jQuery's cache. I didn't dig deep enough yet to find the fix, but on our pages with a fairly heavy table DOM it results in a ~10MB leak per page (because the DOM is retained through the Scope which is retained through the context of the cached data).
This can be reproduced with both ngTasty 0.5.8 (our local version) and 0.6.1 (http://zizzamia.com/ng-tasty/directive/table-server-side/pagination). Steps to reproduce :
You should notice the following highlighted spike that didn't get deallocated from the moment the pagination page was visited
From what I understand, this would happen when DOM nodes are destroyed outside of the jQuery API (i.e. native DOM interface). Is that the case anywhere in tasty ? I didn't find a reference to this kind of behaviour yet...