fix(gen:app:navbar): improve navbar component when using ui-router

[kingcody]

Changes:

• Use ui-sref instead of href or ng-href when ui-router is chosen
• Use ui-sref-active instead of ng-class='{active: isActive()}' when ui-router is chosen
• Use $scope.menu[n].state instead of $scope.menu[n].link when ui-router is chosen (attempt to remove possible confusion)
• Omit $scope.isActive when ui-router is chosen
• Simplify navbar(jade).jade templating (remove extra <% if (filters.auth) %> tag)

closes #436, #331

[JaKXz]

Awesome, thanks @kingcody. There's nothing you're missing from #331 right?

[kingcody]

@JaKXz potentially the change to use $state.go() over $location.path()

Your thoughts?

[JaKXz]

I'd be in favour of $state.go(), leveraging UI-router.

[kingcody]

Then perhaps we should take a look actually leveraging more of UI-router's features when it come to state routing.

• provide url/state for logout
• use resolves to provide Auth.isLoggedInAsync().$promise?
• nested views for navbar and footer

I'm actually using Auth.isLoggedInAsync().$promise resolve in my states with great effect; namely the user doesn't see a template 'upgrade' once the controller has resolved that they are logged in (since the view isn't resolved until the promise is). But I understand that some of these may be too use case.

Either way, would a separate PR be inline to cover these possible changes, as well as switching to $state.go()?

[kingcody]

As for a logout state, we could also make a corresponding route if the user chooses ng-route

In either case, if the URL: /logout was navigated to, or with ui-router state transitioned to as well, the controller could use Auth.logout() and then redirect the user back to the referring URL/state or the site default such as / or /login

This would allow for a more restful interface as well as provide additional functionality such as allowing for: <a href="/logout">Logout</a> in the navbar and other places.

Just my 2 cents...

[kingcody]

Also, I'd be interested in submitting the PR to cover such a change. Not trying to throw extra work on anyone else ;)

[JaKXz]

Those are all good points. Go nuts, @kingcody!

[DaftMonk]

Looks good. I need to start merging things into the canary branch.

[kingcody]

@JaKXz @DaftMonk should I combine this all into one PR? Also what brach should I PR to? master or canary?

[DaftMonk]

PRs directly to canary would make my job easier.

[kingcody]

closing in favor of #451

#451 has been rebased on canary and is a more complete solution