Angular JS - Best Practice for Dashboard

Question

Angular JS - Best Practice for Dashboard

Problem

I am pretty new to Angular JS and am working on creating a Angular JS powered dashboard within a larger Django application. I have read a lot on Angular but still have a few questions on what is the best way to structure an Angular application that will have many independent widgets within.

I understand there can only be 1 app per HTML document along with typically 1 ng-view call on the page, my question is should I be setting up each individual widget as it's own app or is there a way to render and control multiple modules within a single app?

Currently I have ng-app declared at the top of my document

<html lang="en" ng-app="dashboard">

Not sure how I would render the remaining widgets if I can only use ng-view once?

I know this question is pretty subjective and there is probably no perfect answer, just looking for some best practices or functional advice.

Thanks!

Problem courtesy of: xXPhenom22Xx

Solution

Discussion

There is a project that implements widgets/dashboard functionality with AngularJS.

Features:

Adding/removing widgets
Widgets drag and drop
Any directive can be a widget

Live Demo http://nickholub.github.io/angular-dashboard-app

Demo source code https://github.com/nickholub/angular-dashboard-app

Dashboard directive itself https://github.com/nickholub/angular-ui-dashboard

Discussion courtesy of: webdev

This recipe can be found in it's original form on Stack Over Flow.

Accepted Answer

It is pretty subjective, but using multiple controllers or directives, if done properly, can give you the effect you're looking for.

For example,

<html ng-app="my-dashboard">
  <body>
    <div class="Some structuring thing">
      <ng-include src="my-header.html"></ng-include>
    </div>
    <div class="Some other thing">
      <ng-include src="my-sidebar.html"></ng-include>
    </div>

    etc...

  </body>
</html>

Then, each section could be its own, stand-alone component. From there, you can break it down into controllers...

<div ng-controller="my-header-text">
  <p ng-bind="title">

  etc...
</div>
<div ng-controller="my-header-login">
  <p ng-click="login()">Login</p>

  etc...

</div>

And even further with directives.

<my-custom-directive words="user.name"></my-custom-directive>

This example is, really overkill, but the point remains; you've got a lot of ways to control granularity as you like.

Personally, these are the rules I like to follow.

One app per document (as prescribed, and also because it makes sense.)
A new controller for every DOM sub-tree that can stand alone; so my login and dashboard clearly have different purposes, and if I wanted granularity, I could break each one into its own controller, and use services to properly handle communication with the root of my app. I could login to any page, not just the dashboard, and a user could use the dashboard even without the option to log in and out (assuming some default case for non-logged in users), so these sections can stand alone and are decent candidates for their own controller.
I like custom directives for non-trivial HTML chunks. It helps readability and reuse; just always try to use the isolate scope, and if you can't, question if what you're doing is really a directive. Write your directive assuming that it could be used not just by your app, but any similar app that included it and followed the correct API.

Solution courtesy of: Hylianpuffball