4

Is there a best-practice for falling back on ngInclude?

The initial solution I came up with was for the controller (or parent directive, where applicable) to have something along the lines of

scope.someInclude = 'views/x/custom/'+someVar+'.html';

scope.$on('$includeContentError', function(event, failedTemplate){
    if(scope.someInclude === failedTemplate){
        scope.someInclude = 'views/x/default.html';
    }
});

Where the template would simply ng-include='someInclude'.

This doesn't seem like a great solution for several reasons. Among the largest of which being that it won't remember which templates don't work, along with the extra boilerplate.

Before I go building a service to alleviate some of these things, are there any simpler solutions that I'm missing?

DRobinson
  • 4,441
  • 22
  • 31
  • Out of curiosity, what is the point of a fallback? But otherwise, you could just create a directive to wrap `ng-include`, load the template manually and use `$templateCache.put` to store it under the original url. – New Dev Mar 13 '15 at 14:36
  • The current use-case that I'm writing is that there are various pages and each can have its own "info" modal in the common nav (i.e. the nav's directive and template are shared among every page). Many pages can share the same (default) "info", but others have significantly more complex (custom) ones. I figured it might be nice to set it up to look at a path (e.g. 'views/info/custom/pageX.html') for the page's custom info, should it exist. If it does, that's obviously the best thing to show, but if it doesn't then the default (e.g. 'views/info/default.html') would suffice. – DRobinson Mar 13 '15 at 14:45
  • Similar to why one might want a fallback image: http://stackoverflow.com/questions/16310298/if-a-ngsrc-path-resolves-to-a-404-is-there-a-way-to-fallback-to-a-default – DRobinson Mar 13 '15 at 14:46

0 Answers0