masimplo
masimplo

Reputation: 3774

angular ui-router best practice inheritance vs metadata

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.

Upvotes: 10

Views: 2268

Answers (2)

Chexpir
Chexpir

Reputation: 1876

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

Upvotes: 1

BKM
BKM

Reputation: 7079

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.

Upvotes: 0

Related Questions