I have a nested state structure like this:
$stateProvider
.state('main', {
url: '',
abstract: true,
templateUrl: ...
controller: mainController,
resolve: {
Resolve1: ...
Resolve2: ...
}
})
.state('main.state1', {
url: '^/state1/:id/',
templateUrl: ....
controller: state1Controller,
resolve: {
Resolve11: ...
Resolve22: ...
},
})
.state('main.state2', {
....
From what I am seeing, when you are at state main.state1 and you navigate to the same state with another id parameter, the template for main.state1 is rendered fine but the template for main (the parent) is rendered before the state changes (I guess it doesn't wait for the data resolution of main.state1). This results to the view being rendered with the wrong data (more specifically, the state parameters that I use for generating links are wrong).
My mainController has the $stateParams and $state injected to it and that's where I get the data from.
Did anyone notice this before? Is this by design or is it a bug?
Is there any way to update the parent view with the latest data?
However, I would expect ui-router to wait for all data resolutions until it starts rendering the views (even the parent). I don't know if I am missing something here, but this is my understanding of the problem so far...
UPDATE:
I see now that a function that is involved in the view rendering (with interpolation) gets called many times, first with the old values and then with the new values. But the final result that I see on screen is using the initial data that were used when I first entered the 'main.*' state. This is SO weird.
UPDATE 2:
I have found that my links where not updated ONLY when using ui-sref (note that I was using parameters in the state href, e.g. ui-sref="main.state1({id:{{getId()}}})"). When switched to ng-href everything worked as expected.
I have no idea why, but that fixed the problem.
The odd thing was that the ui-sref was evaluated, but the link was not updated.
Go figure...
UPDATE 3:
This solution in turn caused other problems. Then the first click reloaded the application... So this is not the best fix...
The "solution" was to use ng-click with $state.go(), instead of links.
This appears to be a bug in ui-router.
ui-router transitions "through" the parent state to the child. That means main will be triggered, then main.state1. I ran into this myself where I was getting duplicate listeners and HTML DOM elements - main is actually running AT THE SAME TIME as main.state1. This behavior is by design, and AFAIK your only option is to design around it.
Related
I just wondering does anybody know how to debug situation when you have blank page for UI-Router. (Of course, without any errors in console)
By doing console.log for router events(take from here) I found you that it went to correct state but after did not stop on breakpoint inside state controller that I specified in UI-Router state:
.state('invited-user', {
parent: 'authPublic',
url: '/users/invitation/accept?back_link&invitation_token',
templateUrl: 'auth/invited-form.html',
controller: 'InvitedUserController',
data: {
hidePageNavigation: true
}
})
so I guess that controller is a problem.
Already tried to mock it:
.state('invited-user', {
parent: 'authPublic',
url: '/users/invitation/accept?back_link&invitation_token',
templateUrl: 'auth/invited-form.html',
controller: function(){
debugger
},
data: {
hidePageNavigation: true
}
})
but without any result, unfortunately.
I look for solution for current issue and general approach how to debug such kind of situations in general.
So I came to conclusion that the logic of debug should be so:
console.log router events (code is here) to check router logic
check the template of current router state (mock it if needed)
check the controller of current state (mock with empty function if needed)
check all templates and controllers of parent states from current one, starting from nearest parent and going up.
Actually it would be nice to have exception from box to see exact problem, but unfortunately we have what we have.
I have a state named 'index' that, depending on the ui-view on the page, display different information and have different templateUrl and share the same URL:
$stateProvider.state('index', {
url: '/',
views: {
'all#': {
templateUrl: '/templates/partials/all/index',
controller: function(){
console.log('main');
}
},
'#': {
templateUrl: '/templates/partials/home/index',
controller: Controllers.Index,
controllerAs: 'academia',
resolve: {
templates: Preload.go(),
academia: ['Info', (Academia: Academia.Services.Info) => {
return Academia.get();
}],
plans: ['Planner', (Planner: ngPlanner.Planner) => {
return Planner.init();
}]
}
}
}
});
when the page is loaded with a <div ui-view></div>, it works as intended (matching the '#' rule). but when the page is loaded with <div ui-view="all"></div> it doesn't.
A plunkr showing the problem http://plnkr.co/edit/a2SWbB?p=preview
The resolve from the unnamed # shouldn't interfere with the all# view. The current resolve is being rejected because it doesn't belong on the current view (since there's no unnamed view when the page is loaded). Is it a bug, or am I doing something wrong?
At these days, the UI-Router implementation is driven by state management. And despite of the fact, that there are some voices/requirements to split the resolve of the views (well, not the parent view vs child view - but that is discussed below) ... I would say, current behavior in the Q&A described above is simply correct.
Firstly, what is the problem in above question? In general there are two or more sibling views, with their own resolve definitions:
views: {
'view1': {
....
resolve : { // could fail
}
},
'view2': {
...
resolve: { // could fail as well
...
What is state?
A state is a cluster of settings, representing the state. (sounds like self proving statement, but I am serious). All the settings are about state definition, about one, specific state.
We can use more views to represent it (e.g. title and content).
We can use some resolve statements (for all sibling views, for some of them) to support these views.
We have still only ONE state.
And that's it. It is all or nothing. The state is one, one cluster of settings, which all of them must be workign/resolved - or the whole state is failing.
Another story: parent - child
There are also some requirements to let the parent view to render once all its stuff is resolved. Why? Currently, if we navigate directly to child state, all/both resolves must be resolved before the state is initiated, the views are rendered.
That could be really improved. Make sense. And as far as I remember it is planned to happen in later releases (I'would swear I've seen that in one of the comments by UI-Router team member - but cannot find it).
It is different scenario. Because 1) we can go to parent (list view) first. And then 2) select child (detail). In this scenario it could really happen that list is working, detail fails.
So going directly to child should render parent, next fail on a child... But this is different story then the sibling described above.
Suggestions:
My suggestion would be, keep in resolve only stuff which is essential, absolute MUST for a state. Move the rest into Controllers injected services. This is my suggestion and my way...
I was thinking last night about how to port our crud application to a tab based app, like gmail. First, reading a lot about ui-router, i thought in create a tabService that will create a new tab for each state change (listen $rootScope.stateChangeSuccess), the new tab would include the corresponding view (ui-view="bancos") that will display the state template.
My first test and my first problem, when shown the list of items, a click over one of the item (itemId=4 for example) should open a new tab and display the item with id=4 in this tab, inside the corresponding (ui-view="bancos/4"). Note how i'm trying to map named ui-view with states to display the state defined templates in the corresponding ui-view.
I know that ui-router sample seems to do what i'm trying, but they are using nested states with unamed ui-view inside parent state template. In my case, the parent state ui-view element and his child state ui-view element should be sibling.
Considering the nature of angular, tree structured, and the nature of ui-router states, tree structured too, can i use ui-router to implement my requirements (crud application with tab based design).
Regards
Danny
Here is me example, if you have questions i can answer
http://plnkr.co/edit/tqfPVFaesSe9Q6ZkPMzE?p=preview
Short explain: don't use tabs instead of that create a fake, works well and you save a lot of work.
Best
I was looking for the same info, does the following example help you?http://plnkr.co/edit/gMsKK9l7J0B8vZIMIVfD?p=preview (Not my coding.)
Edit:
I've found more useful data.
https://github.com/angular-ui/ui-router/wiki/Multiple-Named-Views
In my code, I have set it up like this:
.state('surveys.list', {
url: '/list',
templateUrl: "survey/surveys_overview.tpl.html",
controller: 'SurveyOverview'
})
.state('surveys.create', {
abstract: true,
templateUrl: "survey/survey.create.tpl.html",
controller: 'SurveyManageController'
})
.state('surveys.create.views', {
url: '/create',
views: {
'details': {
templateUrl: "survey/survey.create.details.tpl.html"
},
'steps': {
templateUrl: "survey/survey.create.steps.tpl.html"
}
}
});
The surveys.create.tpl.html just has a and two tabs with each one div:
<div ui-view="details"> & <div ui-view="steps">
I'm building a dashboard system in AngularJS and I'm running into an issue with setting the url via $location.path
In our dashboard, we have a bunch of widgets. Each shows a larger maximized view when you click on it. We are trying to setup deep linking to allow users to link to a dashboard with a widget maximized.
Currently, we have 2 routes that look like /dashboard/:dashboardId and /dashboard/:dashboardId/:maximizedWidgetId
When a user maximizes a widget, we update the url using $location.path, but this is causing the view to re-render. Since we have all of the data, we don't want to reload the whole view, we just want to update the URL. Is there a way to set the url without causing the view to re-render?
HTML5Mode is set to true.
In fact, a view will be rendered everytime you change a url. Thats how $routeProvider works in Angular but you can pass maximizeWidgetId as a querystring which does not re-render a view.
App.config(function($routeProvider) {
$routeProvider.when('/dashboard/:dashboardId', {reloadOnSearch: false});
});
When you click a widget to maximize:
Maximum This Widget
or
$location.search('maximizeWidgetId', 1);
The URL in addressbar would change to http://app.com/dashboard/1?maximizeWidgetId=1
You can even watch when search changes in the URL (from one widget to another)
$scope.$on('$routeUpdate', function(scope, next, current) {
// Minimize the current widget and maximize the new one
});
You can set the reloadOnSearch property of $routeProvider to false.
Possible duplicate question : Can you change a path without reloading the controller in AngularJS?
Regards
For those who need change full path() without controllers reload
Here is plugin: https://github.com/anglibs/angular-location-update
Usage:
$location.update_path('/notes/1');
I realize this is an old question, but since it took me a good day and a half to find the answer, so here goes.
You do not need to convert your path into query strings if you use angular-ui-router.
Currently, due to what may be considered as a bug, setting reloadOnSearch: false on a state will result in being able to change the route without reloading the view. The GitHub user lmessinger was even kind enough to provide a demo of it. You can find the link from his comment linked above.
Basically all you need to do is:
Use ui-router instead of ngRoute
In your states, declare the ones you wish with reloadOnSearch: false
In my app, I have an category listing view, from which you can get to another category using a state like this:
$stateProvider.state('articles.list', {
url: '{categorySlug}',
templateUrl: 'partials/article-list.html',
controller: 'ArticleListCtrl',
reloadOnSearch: false
});
That's it. Hope this helps!
We're using Angular UI Router instead of built-in routes for a similar scenario. It doesn't seem to re-instantiate the controller and re-render the entire view.
How I've implemented it:
(my solution mostly for cases when you need to change whole route, not sub-parts)
I have page with menu (menuPage) and data should not be cleaned on navigation (there is a lot of inputs on each page and user will be very very unhappy if data will disappear accidentally).
turn off $routeProvider
in mainPage controller add two divs with custom directive attribute - each directive contains only 'templateUrl' and 'scope: true'
<div ng-show="tab=='tab_name'" data-tab_name-page></div>
mainPage controller contains lines to simulate routing:
if (!$scope.tab && $location.path()) {
$scope.tab = $location.path().substr(1);
}
$scope.setTab = function(tab) {
$scope.tab = tab;
$location.path('/'+tab);
};
That's all. Little bit ugly to have separate directive for each page, but usage of dynamic templateUrl (as function) in directive provokes re-rendering of page (and loosing data of inputs).
If I understood your question right, you want to,
Maximize the widget when the user is on /dashboard/:dashboardId and he maximizes the widget.
You want the user to have the ability to come back to /dashboard/:dashboardId/:maximizedWidgetId and still see the widget maximized.
You can configure only the first route in the routerConfig and use RouteParams to identify if the maximized widget is passed in the params in the controller of this configured route and maximize the one passed as the param. If the user is maximizing it the first time, share the url to this maximized view with the maximizedWidgetId on the UI.
As long as you use $location(which is just a wrapper over native location object) to update the path it will refresh the view.
I have an idea to use
window.history.replaceState('Object', 'Title', '/new-url');
If you do this and a digest cycle happens it will completely mangle things up. However if you set it back to the correct url that angular expects it's ok. So in theory you could store the correct url that angular expects and reset it just before you know a digest fires.
I've not tested this though.
Below code will let you change url without redirection such as: http://localhost/#/691?foo?bar?blabla
for(var i=0;i<=1000;i++) $routeProvider.when('/'+i, {templateUrl: "tabPages/"+i+".html",reloadOnSearch: false});
But when you change to http://localhost/#/692, you will be redirected.
I'm using the new angular-ui router, the one that has a state-machine included (https://github.com/angular-ui/ui-router). This great router allows a user to specify parameters as part of the URL.
for example:
$stateProvider
.state('contacts.detail', {
url: "/contacts/:contactId",
templateUrl: 'contacts.detail.html',
controller: function ($stateParams) {
// If we got here from a url of /contacts/42
expect($stateParams).toBe({contactId: 42});
}]
})
(see here)
this means, that when the user navigates to /contacts/42, the state is changed to 'contacts.details' and the 42 parameter is injected into the controller
There is a problem though. If ONLY the url parameter changes, the transitionTo function is still being called (could happen if the url is changed manually, for example, or bound to a input box). this in turn leads to the view directive of that state, to be re-created, both a waste of time and a problem if we only wanted to update something in that state.
it seems to be on purpose. from the code:
// Starting from the root of the path, keep all levels that haven't changed
var keep, state, locals = root.locals, toLocals = [];
for (keep = 0, state = toPath[keep];
state && state === fromPath[keep] && equalForKeys(toParams, fromParams, state.ownParams);
keep++, state = toPath[keep]) {
locals = toLocals[keep] = state.locals;
}
equalForKeys is what compares the params, and return false if there's a difference.
My question: do you know why the author would have written it this way? do you think its safe to change, so that there's no transition when only parameters would change?
thanks very much for reading all the way till here, and for any idea
Lior
EDIT: Seems that this is by design. just found: https://github.com/angular-ui/ui-router/issues/46
I generally solve problems of this nature with abstract states and nesting. Place the pieces that don't change based on the url parameter into the abstract parent state and you'll avoid the extra server hit. I prefer to place them into the resolve or custom data section in the parent state, but if necessary you can retrieve them via scope inheritance. Be sure you read and understand the rules of scope inheritance as there are some things that (at least for me) were unexpected.
You can read more details here: https://github.com/angular-ui/ui-router/wiki/Nested-States-%26-Nested-Views. In addition, the sample application included with angular-ui is a good place to start understanding state nesting.