There are two ways (AFAIK) to associate a controller with a view template/partial: the route specified in $routeProvider and the ngController directive. Especially (but not exclusively) for simple routing, is there any benefit/efficiency of one over the other?
My project currently uses the $routeProvider approach, but I've been given the task of nesting views. This seems simple enough with ngInclude, as long as the partial specifies its ngController.
This question really comes down to design and as such it is a bit opinion based. That in mind, the best guidance I know is:
$routeProvider - Allows you to specify a single controller for a template. Since this is part of the routing it makes it easy to find the controller that goes with the page. I use this to store and load overall page logic rather than element specific logic.
This is also important because it means you can load the exact same template for two different routes but the behavior and data could be different because the controller can be changed. This is not something that is easy to do with the ngController option.
ngController - This scopes the controller to a specific element on the page/template. That can make the code easier to read when you need multiple controllers on a single page and it allows the controller to be more specifically scoped.
So it really comes down to scope and intent. Hopefully these rules will help when deciding which to use.
If you think of a view including all scripts as a self-contained package, developed by a single person or team, then ngController is the way to go, imho.
$routeProvider on the other hand provides you with advanced features like injection of values via the resolve property of the route. That way you can have your AJAX loaded data directly injected into your controller, e.g., instead of the controller having it to get itself. Or have the route change to wait for that data etc.
Btw: If you need routing and nested views you can take a look at angular ui-router
Related
I've been reading up a more in depth about angularjs directive and controller, what should be in one and the other. The situation is this, I have multiple people with their types -> policemen, medicine, lawyers ... etc. inside the admin panel app, where the admin can manage them. In one section the admin can create, edit, delete them. The current versions controller does almost all the work: UI (bringing up the right form, hiding the other forms...), and logic (deleting, creating, updating methods for each person type). As I understand this is not good, because the controller does multiple things (no single responsibility). And even further the controller should only bind values to scope.
But does that mean, that I should only pull all the people (inside controller) and pass it some master directive which will manage it all? Or should their be more directives inside directives to divide the responsibility?
And if so, the controller will have to use the same service as the directive/directives. Controller for pulling people from back-end) and the directive/directives (for creating/updating/deleting) is this DRY?
Without code it's hard to give a precise answer, but the general idea when working with angular is this:
Controller: The controller is responsible for keeping the views up to date with all the changes that are happening throughout your app. This means that it should not contain the business logic, this logic should instead be separated into small services. Each handling different parts of the logic for your app.
Service: As stated above, a service should contain your business logic. Meaning that heavy calculations, manipulations etc. should be put into a service. Since services are singletons you can easily inject this service anywhere and re-use the logic within it, something you cannot do if you've put your logic inside a controller.
Directives: Like controllers, directives shouldn't have any business logic in them. Directives are only there to create re-useable functionality as well as giving you a place to handle direct DOM changes. DOM changes should never be done anywhere but from within a directive.
To answer this:
And if so, the controller will have to use the same service as the directive/directives. Controller for pulling people from back-end) and the directive/directives (for creating/updating/deleting) is this DRY?
If you have the data bound to a controller, you should not necessarily need a directive to handle the CRUD operations. Since the data is bound to the controller, you can easily create a template which reacts to the data changes automatically using ng-repeat, ng-if and so on.
I'm working on an isolated scope custom directive that has a few different states.
Does it make sense to use ui-router/ui-view inside this directive in order to handle the states?
It's a "note widget" that lists notes. If there are no notes, it displays a message instead of the list that says they should add a note. If notes are being loaded, it shows that notes are being loaded. If a user adds a note by clicking the add I mentioned above or the + then the view is a textbox. So there is at least 4 different views.
My initial instinct is that it would be polluting the directive and giving it a hard dependency to ui-router and my application because it defines the states. Am I just over worried?
I would tell it this way: yes, use the ui-router, but not for a directive - use it for your appliation. In fact, the best you can do is to read few blog posts and go through sample application to understand the principles. You'll soon realize, that there is no need to use the ui-router partially..
from The basics of using ui-router with AngularJS (by Joel Hooks)
...ui-router fully embraces the state-machine nature of a routing system. It allows you to define states, and transition your application to those states. The real win is that it allows you to decouple nested states, and do some very complicated layouts in an elegant way.
You need to think about your routing a bit differently, but once you get your head around the state-based approach, I think you will like it...
and here AngularJS State Management with ui-router (by Ben Schwartz)
...The most interesting thing about AngularJS's new router, isn't the router itself, but the state manager that comes with it. Instead of targeting a controller/view to render for a given url, you target a state. States are managed in a heirarchy providing inheritance of parent states and complex composition of page components, all the while remaining declarative in nature...
Here I put together all the links, up to date, targeting the sample example, the most interesting code snippet sample.js..
Summary, try to implement the ui-router on the application level. Directive could then by a conductor only, helping your users to navigate, to walk through among states...
I am converting my application from ngRoute to uiRouter. I have read and watched a lot of tutorials but I am still lacking the experience to decide on best practices.
First of all a major change I have done is break the state declaration to each module/controller. This feels more natural and cleaner to me but introduces some complexity when wanting to apply a global rule to many states. For example half my routes require authentication and the other half do not.
With ngRoute I had a data attribute denoting the auth level required in each route. With uiRouter I understand there is this way of doing it and there is the state inheritance way. So a route could be public.myRoute where public is an abstract route declared at the application level. This creates the issue though of the module not being able to work standalone if someone does not define the public state.
In contrast if I add a metadata attribute in the data object, like "auth_level: user" this would not affect the module if no one is dealing with it. But this feels more "magic" and less maintainable.
The same issue arises with the navigation bar. Half my views have a navigation bar and the other half don't. Until now I used a isNavbarVisible boolean attribute but I understand this should be part of the state? Maybe a second ui-view in the layout.html template instead of using ng-include with ng-if as I did so far?
Finally, I am wondering about the best practice in requiring a promise in every route to be resolved. For example, no matter where the application entry point is, the user rights should be resolved first before loading the view. In ngRoute I was looping through all the routes in their definition and adding that promise.
Is there a good guide for best practices when migrating from ngRoute to uiRouter, because other than generic recommendation like "replace ng-include" with a name ui-view or that state inheritance should be preferred, I haven't found any concrete implementations demonstrating that.
I am in the same situation than the question author, Here's some very interesting information about how to drive this change.
https://github.com/angular-ui/AngularJS-StyleGuide
ui-router is a 3rd-party module and is very powerful. It supports everything the normal ngRoute can do as well as many extra functions.
Here are some common reason ui-router is chosen over ngRoute
ui-router allows for nested views and multiple named views. This is very useful with larger app where you may have pages that inherit from other sections.
ui-router allows for you to have strong-type linking between states based on state names. Change the url in one place will update every link to that state when you build your links with ui-sref. Very useful for larger projects where URLs might change.
There is also the concept of the decorator which could be used to allow your routes to be dynamically created based on the URL that is trying to be accessed. This could mean that you will not need to specify all of your routes before hand.
states allow you to map and access different information about different states and you can easily pass information between states via $stateParams.
You can easily determine if you are in a state or parent of a state to adjust UI element (highlighting the navigation of the current state) within your templates via global $state provided by ui-router
Overall, ngRoute merely allows you to assign controllers and templates to URL routes, whereas the fundamental abstraction in ui.router is states, which is a more powerful concept.
I am a total Angular (and JS) beginner.
I want to develop something like this:
(with apologies to #PhillipKregg for borrowing his excellent illustration).
Effectively, I want nested tabbed notebooks - a row of tabs (views?), each which can contain data or another row of tabs (each of which ...).
Googling seems to return more recommendations for UI-Router, but I imagine that UI-Bootstrap's Tabs or Accordion could also be used (or even UI-Bootstrap's Pagination, with a single view whose contents I update according to the selected page?).
All else being equal, I will go with whichever is easiest for a novice to understand and implement (which is that?).
But - are there performance issues? For instance, will one download the content of all the views immediately or initial page load (thus increasing initial page download time)? Will one only download the data for a view when it becomes active (which seems preferable)?
Anything else I need to consider?
Yes, ui-router & ui-bootstrap.tabs are the best tools for the job at the moment. To do something similar would require mixing two types of ui-router config patterns, nest views & multiple named views. I'd suggest reading both these wiki pages:
https://github.com/angular-ui/ui-router/wiki/Nested-States-&-Nested-Views
https://github.com/angular-ui/ui-router/wiki/Multiple-Named-Views
Here's a basic draft demo of something similar to your illustration, using ui-router & ui-bootstrap.tabs: http://plnkr.co/edit/BUbCR8?p=preview
The easiest way to get started is to use ng-boilerplate https://github.com/ngbp/ngbp, it uses ui-router & has best-practice directory structure. It also addresses performance issues by compiling html to js & adding templates to $templateCache, thus kicking lots of XHR requests to the curb.
Regards to data downloads, data would typically be managed by a angularJS service singleton instance, separate from any views. How & when you invoke any service from any view is totally your choice. This is a pretty good tutorial on angular services: http://www.ng-newsletter.com/posts/beginner2expert-services.html
I would recommend to use angular $routeProvider for your task. This will make easy to handle code and view fragments.
With bootstrap you will need to put all the code on single page and that is less manageable. Have a look at
http://viralpatel.net/blogs/angularjs-routing-and-views-tutorial-with-example/ and
For nested views
http://www.bennadel.com/blog/2441-Nested-Views-Routing-And-Deep-Linking-With-AngularJS.htm
Also $routeProvider is better for navigation. Back Forward through view...
Angular will load views when required.(Lazy loading.) So better for performance...
Hope this will help.
I personally don't get the point of wanting to use bootstrap tabs with angular's ui-router. It is counter-intuitive. Just don't use bootstrap's tabs and set up the "sub-tabs" in the angular config. This will also make your code more readable. Only add ui-bootstrap if you NEED the extra features. An example config is below
$stateProvider.state('A', {
url: "/A",
controller: "testController",
templateUrl:'pages/A.html'
})
.state('A.B', {
url: "/A/B",
controller: "testController2",
templateUrl:'pages/A.B.html'
})
I use ng-view to pull in a partial to page. After that I would like to load in another partial to the page that would be right next to the initial partial that was brought in.
How would I bring in another partial from a angular controller?
Because of how ngRoute was designed, you can only have one ng-view per ng-app instance.
However, it looks like you are looking for ng-include since the routes do not seem to come into play.
Otherwise, to work around the issue of URL routing having only one template, you have two options:
Use ui-router Note: Under heavy development, may introduce breaking changes.
Define and use two angular applications which can reuse the controller/service code. However, then the two applications will not be able to share state.