Angular.js best practice - extending controllers, overriding controller defaults

Question

Here is a real-life Angular problem I can't wrap my head around. I love Angular, but this issue is bugging me a lot right now.

What is the best practice to extend an existing controllers's functions, and use the extended controller on an other page of my application? In other words: How to do controller inheritance in Angular?

Edited out - 23/09/2014, dont think the description of my original usecase helps the visitors to understand it better what I'm after here. I think it disctracts people from the real issue.

Answer 1

After half a year I think I understand completely what's going on. As it is pointed out in a comment to this post, the simplest answer is services.

In the most optimal case, all your scope variables are values gathered from a factory/service. Still, you might want to use the exact same controller with one extra function: $scope.someFunction(){}, and keep the rest. In this case, you do have a 'thin' controller logic, which is the desirable controller design - but may still end up a hundred or more lines of code. You don't want that being duplicated in an other controller, just because you need some extra controller logic (like $scope.someFunction() )

What do you do then?

The answer is this:

1. Make sure that you did everything in order to solve the situation with factories

2. if you are abolutely certain you did, go for the controller injection:

   .controller('childController', function ($scope, $controller) {
     'use strict';
     $controller('parentController', {$scope: $scope});
     $scope.someFunction=function(){}
   })
   

It's that simple. -- again, usually, things can be solved with factories..

Hope you find this useful ;)

Answer 2

Abstract

The problem you are referring to, looks to me like generic code reuse problem for which there is standard solution in the field of computer studies (invented back in previous century), i.e. inheritance. Unfortunately due to numerous reasons OOP didn't obtain wide adoption in JavaScript community, one of them is the fact that it wasn't core feature of the language. Another one is the fact that developers are open to creating their own approaches at solving the same problem. And by creating these different approaches developers partition the community into parts that deal with inheritance in different ways.

It leads to blurring of whole idea of OOP and makes people scared of those three letters. In my practice I've met dozen's of people saying that JavaScript isn't made for OOP and raising points like "JavaScript it's a functional language", or "inheritance is an anti-pattern" or "Don't do things for which JavaScript wasn't intended for". But when you ask these people what OOP is?... Typically none of them can provide an answer. So having an opinion is great but it has to be attached to some investigation.

Answer

So answering your question, I would propose using John Resig's JavaScript inheritance approach, which described in detail within the following SO post: angularjs with oop inheritance in action