My application has two views, each of these has two routes. When a user change the route of one view, the other should not be changed. This is achieved using sticky states.
One of the routes uses a resolve to go grab something from the server. In my application this is dependent on a route parameter which is simulated in the plunker I put together by returning a random number.
The issue is that the resolve only fires once which means, regardless of the route parameter, it ends up loading the same content and redirecting to the same URL every time.
Worse yet, adding {reload: true} to the state causes this error: state.params.$$keys is not a function. I've started reading the source but figured I should post here in case anyone had seen this before.
I would prefer not to refactor the app to avoid parallel states, and so would appreciate any other suggestions.
You are running into issue #112
https://github.com/christopherthielen/ui-router-extras/issues/112
I built from source and updated your plunk and it seems to be working correclty now when transitioning back and forth between ViewB RouteA and Route B
http://plnkr.co/edit/zpEXaJqXtJPH1pVKPVxj?p=preview
Stupid stackoverflow requires me to add code to the answer since i linked to a forked plunk. there's no code to add
Related
I have been following the concept of componentalization, and is an advocate of it, but kind of looking for a solution for a normal scenario below. It could be that my approach is wrong and must be changed, or something I am unaware of. I have been looking everywhere and trying out many things, but havent seen a success. It must be something I missed out.
I want to add a componenent with internal routing. Basically, the idea is this component can exist on any page, but uses a relative route from its parent to be in a particular state.
The requirement is that it can exist in different tabs which has states and it has to be a directive.
Can someone help me out with this concept or point me in the right direction? Would want to implement it in AngularJS 1.4
Edited
The below image depicts the scenario. Can we place the register component/directive in any tab, be it dashboard or tab2 or tab3.
We also have states in the Register component( I understand that states work in when config runs), but those are to be handled in the component code, but should stay independent of the parent route, like a standalone component.
eg: if component ABC is in page1, the route should be page1/ABC/step1
if later we decide to move it to another page, the route should be page3/ABC/step1 and this has to be done without adding the routes "page.ABC.step1" and "page.ABC.step2"
So the idea is to move around the directive without changing route configs.
I hope I have conveyed the idea properly. If you need more do let me know.
I'm wondering whether to use angular UI router or just use simple ng-include, i'm failing to fully understand why would i pick to include entire library over the built-in ng-include which gives me about the same functionality with less code?
Can someone explain whats wrong with
<div ng-if="somestate" ng-include="someview"></div>
Can someone explain whats wrong with
<div ng-if="somestate" ng-include="someview"></div>
It doesn't handle URLs in any way. You want the URL to change when you go to another state, and you want the state to change when the URL changes. You want to be able to bookmark a page in your app, or send its URL by email, and come back to this page rather than the home page when opening the bookmark or the link.
It also doesn't allow resolving data before switching to a state.Both ui-router and ngRoute allow doing that: the state changes only when the data needed to display this state has been successfully loaded.
That's the main job of ui-router and ngRoute. ui-router has many other goodies, like events when changing state, named views, state inheritance (very useful to handle a view consisting of several tabs, for example), etc.
I recently posted this question and figured out the direct solution (that being, I was able to cancel a promise/request when the route changed). However, I'm encountering another, related problem that I think belongs in a separate question so here it goes:
I'm able to abort my promise when the route changes just fine (as you can see from the question I linked). However, for some strange reason, any other requests on the other route are delayed when resolving. See my dev tools screenshot below.
Here's the scenario: I load route A, which makes the call to /api/categories and you can see it takes 30ms which is normal. Then I navigate to route B, then before it's done loading I return to route A. When I return, the call to /api/categorySites/1 is cancelled, and you can see when that happens as the gray bar ends. This is done by aborting the promise. However, back on route A again, the call to /api/categories doesn't resolve until that gray dot appears again on the request that was cancelled. That second call to /api/categories shouldn't take 2.23s, it should be closer to 30ms.
What's going on here? I would think the second Route A request would be just as fast as before. I need to get this to work faster. My code is in this question. Let me know if you think I should include it again here. It's hard for me to imagine this isn't a common problem too...
This is an older post but I did look into this and this sounds like eager vs. lazy asynch transition that I read about in Emberjs documentation recently. On your routes (and subsequent aborts) fulfills the promise (completes), moves along to your re-route request.
I believe this can be improved with a state controller.
There is an Angularjs ui-router state controller that might be of use.
Here are example examples.
Angularjs routing documentation (for posterity).
So this is about $routeProvider (Angularjs default) enhanced by $stateProvider (ui-router) to expedite aborted routes.
Hope this is helpful (roughly 312 days later).
The biggest problem is that I even don't really know how to describe the problem I'm asking about. It's the first time in more then a decade of wed development.
I'm working on a Rails 4.1.1 app and using angularjs pretty extensively, though I don't know it well yet. And everything seemed to be working fine up to the moment when I tried to add some browser history manipulation to my app (e.g. changing the displayed url when listing though a paginated list so that that url can be copied and distributed). To do this I added a config to my app.
#app.config ($locationProvider) ->
$locationProvider.html5Mode(true)
And then in my angular controller added the $location binding like this
$scope.$watch 'pagination.cur', (newVal) ->
$scope.loadNews newVal
$location.path("/news").search({page:newVal})
(this is ment to change the url in the browser searchbox when the user goes from one page to another).
That workes well, the url does change appropriately, but all the sudden all the html links on the page got broken. I mean litteraly. I click any link on the page (even outside the controller div), the url in the serchbox changes appropriately, but the turbolinks toes not fire the Ajax request to get the new page content. If I then refresh the page, it loads the correct page.
I know it's really weird. What's weirder, that I don't get any JavaScript errors or anything unusual.
The only way I found to get the links working again - is to remove that initial config.
But when I do it, the $location falls back to hashtag syntax, wich is really not at all what I want.
My only assumption is that there could be some kind of a conflict between angular $location service and turbolinks when handling browser history, but even if that's right, I have no idea how to get around it. And I really need that kind of manipulation, 'cause I'm going to be using it alot in this and other apps.
I really don't know, what other information on this problem may be usefull, don't hasitate to ask for updates. I'll post whatever I can.
P.S. Btw, can this kind of manipulation be done by means of turbolinks? 'Cause it's exactly the same thing turbolinks does when changing the displayed url after page body reload, but I can't find any documentation on its public API for that.
UPDATE
Have no idea what's the source of the problem yet, but it seems to be not related to the turbolinks gem. Removing turbolinks requirements from the application.js file does not change anything.
Using $window.history.pushState instead of $location.path solves the functionality problem, but does not explain the initial bug.
Okay I have googled and googled and can't find anything related to my actual problem.
Basically I have a simple router defined with a few routes all of which can be rendered directly by the server if called directly.
So the backbone history is called like this.
Backbone.history.start({
'pushState': true,
'silent': true
});
I then have simple a very simple navigate
this.navigate($(event.currentTarget).attr('href'), {
'trigger': true
});
This all works correctly except for one flaw.
Lets say you start on the home page of the site which I do not have a backbone route defined for and then click a few links on the site that use the backbone router, you will get routed to the correct page and everything is fine, but then when you click the browser's back button to get back to the home page you end up seeing the contents of the first backbone route and not the actual homepage's contents.
So I am realizing that I need to store the initial page contents so that I can reinsert them into the page once I detect that I am back to the initial page that does not match a route in my Router, and then from there I need to reload in the stored version of my page.
So I would like to know if this sounds right, or if I am going down the wrong path, also does backbone offer anything to help with this scenario that I am just missing? And I can't be the only one who has tried to do this so how have others gotten around this issue?
(Initially I thought there was actually a problem with my code, and not actually this fundamental issue, so I still want to ask this question to figure out how others have accomplished this)
You need to define a route for the homepage. What happens is that each time you follow a link, the current URL is pushed on pushState's stack, and each time you hit the back button the previous URL gets popped and Backbone tries to follow its route. However, when you pop the homepage URL, there's no route that it matches so Backbone doesn't actually do anything, leaving the content as whatever it was the last time a route really did match.