$parent in AngularJS… Good idea or Bad idea?

The setup…

This post comes from a recent implementation I completed using Angular 1.x. The sprint consisted of implementing a single page website which allows the user to search and display a listing of YouTube videos via Google’s Youtube API. During the implementation of this project I attempted to set a variable whose scope was two levels up located at the parent object of the parent object. The line of code utilized (which is not recommended ) was


The purpose of this post is to talk a little bit more about 1) Why this worked 2) What are some alternate approaches to access parent scope and 3) What are the right and wrong ways to use $parent. Angular is an opinionated framework and as such will allow/disallow certain calls and access to variables and functions however trying to understand the intent behind why certain features are built into a language or framework will help you as a developer to write cleaner code.

1. What is $parent?

Angular utilizes a prototypal inheritance hierarchy for scope access starting with $rootScope at the highest (most parent) level followed by a number of child hierarchies. Typically underneath root scope you will have $scope which provides access to your current scope along with one or more levels of $parent scope depending on where you are in your hierarchy.

What is the purpose/intent behind it

So the documentation that Angular provides is pretty sparse and if you are able to find some details that are directly from the source feel free to let me know. This is the one page I found regarding $parent and this is the page I found where they discuss scope a bit further. My best guess would be that since Angular guides you into creating component-based structures via the use of Directives and Components, this creates a tree-like structure which is similar to the DOM and as a result $parent provides you with quick/easy access to the parent nodes and their scopes.

2. How is $parent used in AngularJS?

Source: https://www.pluralsight.com/guides/front-end-javascript/angularjs-models

3. How did I use $parent?

My project was to build a simple video player page which consisted of an index.html page with a main Component for the application. The App Component was further broken down into a component for the video player, a component for a Video List which consisted of components for individual Video entities and a Search Component to allow the user to search for videos. The app component scope consisted of 2 variables, one for the currentVideo (which would render via the video player component) and one which was a list of all videos (which would render via the video list component.

Once the user selected a specific video title I needed to update the current video variable located in the App Component needed to be updated. One possible solution to this was to access the parent scope via $parent. App Component > Video List Component > Video Entity Component. As a result, I accessed the currentVideo variable by making the $scope.$parent.$parent call displayed below.

Initial $parent code

.controller('videoListCtr', function($scope) {
//some code here...
.component('videoList', {
bindings: {
videos: '<'
controller: function($scope) {
this.onClick = function($event) {
$scope.$parent.$parent.$ctrl.currentVideo = this.videos[Number($event.target.id)];

templateUrl: 'src/templates/videoList.html'

Nested Structure

<div Main App Component>

<div Search Component> .

<div Video Player Component> .

<div Video List Component>
<div Video Entity Component> .


4. What I should have done — a better approach

One alternative (which I refactored to) is to inject any dependencies that your components need into the components via bindings. Rather than access parent level scope via $parent I could provide the lower-level components with what they need to access by passing those items from the parent to the children. Or better yet rather than passing individual items (i.e. parameters) I could pass getter and setter functions which would allow access to the child components. For example:

Parent Container

let ParentController = function(videoData) {
this.videos = videoData;
this.currentVideo = this.videos[0];
this.selectVideo = (video) => {
this.currentVideo = video
.component('parent', {
controller: ParentController,
templateUrl: 'src/templates/parent.html'

Parent Template

<div id="app container">

<!-- Some additional non-pertinent html code -->
<div class="col-md-5">
<video-list videos="$ctrl.videos" on-click="$ctrl.selectVideo"/>

Child Container

let ChildController = function(videoData) {
//some additional non-pertinent code
.component('child', {
bindings: {
videos: '<',
onClick: '<'
controller: ChildController,
templateUrl: 'src/templates/child.html'

Final Child Template

<li class="video-list-entry media">

<!-- some additional non-pertinent code -->
<div class="media-body">
<div class="video-list-entry-title" ng-click="$ctrl.onClick($ctrl.video)">

5. Good idea or Bad idea?

In AngularJS you have the ability to modify data anywhere in the application through scope inheritance and watches. This is very useful and helpful however it can also lead to problems when it is not clear which part of the application is responsible for modifying the data and also when prototypal hierarchies change by adding or moving layers (components or directives) in your application. This is one reason why AngularJS provides component directives with isolate scope functionality, so a whole class of scope manipulation is not possible and changes to data in one component cannot affect other components.

In general using $parent is generally a bad idea and is considered an anti-pattern and bad architectural design to use $parent. If the prototypal chain of your code changes or scope changes in a directive it could break your chained $parent call. Additionally, seeing a call similar to the one above in Section 3 makes for unclean code which is difficult to read as it is had to immediately see the mean of this call. A cleaner call would be something similar to what is listed in Section 4 above.

Originally published at DECODING SOFTWARE.