Contents loaded by ui-view directive not properly connected to rest of DOM...?

[xiehan]

Hi there:

I'm successfully using UI-Router on a very large production project and currently using Angular v1.2.0-rc.2; things are currently stable and I have not run into any issues since we're not using any animations right now. UI-Router has been a lifesaver since Angular's ng-view was far too limiting for what we needed to be able to do with our UI; thanks a lot for all your hard work! 😄

The issue that I've run into actually has to do with a separate project. Our company also has a home-grown system for tracking usage data and providing analytics for how our products are actually being used. Now that our app (which is also our first product using Angular) is getting ready to be released into the wild, I've been working on the tracking script that will collect the usage data based on our predefined metrics.

To provide a little bit of background information: the relevant part of this tracking system consists of 2 parts, the base library and the app-specific tracking script. Both are written in jQuery, since the same tracking system is also used to track other, older apps which are not using Angular or any other front-end framework. In a nutshell, the tracking works primarily by just attaching delegated event handlers such as $(document).on('click', '#someID a.someClass', extractorFunction(event) { ... }); where the extractor function grabs some other data (eg. the element's ID, or a regex of the element's HREF attribute, or perhaps one of its ancestors' IDs in order to record some sort of contextual data) and then ultimately sends that extracted information to another server. The system is stable and working well for all our other apps.

Now, after going through and writing the tracking script for our Angular app (which I have a lot of experience in now, having done it for all our other apps) I noticed that only about 50% of the specified trackers in this script were working properly. Of the others, they were either not tracking at all (that is, their event handlers were just not being fired), or their extractor functions were not extracting the proper data.

After hours of debugging, I finally figured out that the problem is that even though the DOM tree appears fine, relationships appear to be broken whenever the ui-view directive is used. For example, an element inside of one ui-view might properly fire its event handler (extractor function), but if that extractor function relies on $(element).parents() to get some contextual data, that function only returns the DOM tree up to, but not including, the element with the ui-view directive attached. In another case, a tracker such as $(document).on('click', '#someID a.someClass', extractorFunction(event) { ... }); might not fire at all if #someID is declared in one ui-view and a.someClass exists inside a different (nested) ui-view.

I assume this isn't the desired/intended behavior -- but correct me if I'm wrong. I also don't know if this is related to, and might potentially be resolved by, the larger-scale refactor of ui-view that I saw is already in progress. I have no idea how this compares to how Angular's own ng-view functions, as I haven't used it in months and at this point there's no way for us to go back to it.

If this does indeed turn out to be a bug, I realize this might not be a trivial fix, but I just wanted to confirm the issue first before I make any large-scale changes either to our app or to the tracking script.

Thanks, and let me know if you need any more information! I can't really provide any sample code as-is, since both projects are far too huge to port to, say, Plunkr, but if needed, I can try to create a small dummy project tomorrow to illustrate the issue.

[nateabele]

Thanks for the detailed write-up. A small dummy project would help out a lot. Whatever you can do to isolate the problem down to the minimum number of lines possible to reproduce the issue.

[xiehan]

All right, I finally got it:

http://embed.plnkr.co/XciBTM/preview
Make sure that you open your JavaScript console, as it's printing to there.

I'm not sure if this could be considered the minimum number of lines possible -- sorry -- I actually started on the wrong track first, where when I couldn't immediately reproduce the problem, I just kept adding increasing layers of complexity to more closely mimic our production app (multiple nested ui-views, lots of use of ng-class and ng-if directives, and a couple of ng-includes also).

However, I just realized that the one thing I had failed to mimic initially was the way that the actual links themselves worked. In my first several attempts I was using plain old external links (Google, Github, etc.). Then when I was almost ready to give up trying to reproduce the problem, I realized that if I were to be really true to the original app, I should be using links to the different internal UI states, the way our app also works in production. That's when I finally managed to reproduce the problem.

As you can see in the example, there are two lists of 3 URLs each. I left the list of external links in there to demonstrate what SHOULD happen: 2 event handlers from the tracking script fire, one just printing "clicked" to the console, and the other printing the entire DOM ancestor tree of the link element. The internal/state-based links demonstrate the problem behavior: the 'clicked'-printing event handler never fires, and the other is missing the top 4 levels of the DOM ancestor tree of the link element.

It's also worth noting that in my example it's using the ui-sref directive, but I still get the same problem behavior if I use good old-fashioned ng-href to construct the internal links.

So it seems like the problem may not be with ui-view perse, but more with the way that internal links are either constructed or processed...? The one repeated nemesis of our tracking script has been event.stopPropagation(), but I didn't actually find it being used in UI-Router's source code, so it doesn't seem like that's it.

[dlukez]

Hey @xiehan, I replicated the same problem using a more succinct plnkr and seem to have found a fix:

http://plnkr.co/edit/4g6q2XmlJ5rqgHJgxvFD?p=preview

You should see that version working. If you go to the ui-router.js script at line 1394, you'll see that $state.$go is wrapped in a $timeout call. Commenting out the $timeout call and uncommenting the scope.$apply should result in your problematic behaviour outlined above. The mentioned code is in the ui-sref directive (stateDirectives.js) if you need to make a quick change to a local build.

I believe what was happening is the view template was being detached prior to the event being received at the document level as a result of the state change. The $timeout makes it wait until after the event is done with.

EDIT: There's also a directive there that was used to test the same thing. It got the same results as the jQuery version for me.

EDIT 2: Haha I just realised it may be worth testing against your plunk now. Here's an update of your plunk with that ui-router code in there: http://plnkr.co/edit/6DLxGF?p=preview - does it seem to work as expected?

[nateabele]

@dlukez Not sure what I'm missing here, but the results of both (i.e. using $timeout() or using $apply()) appear to be identical.

[xiehan]

@nateabele They're not. If you only use $scope.apply(), both event handlers fire but the first one returns incorrect results; $element.parents().length is only 11 instead of 13.

@dlukez Thanks so much! This really does seem to be doing the trick. The only thing is that unfortunately just doing a local build isn't going to work for us; we're using Bower to manage package dependencies, so at the very least I'd need a forked repo with the solution that we can reference in our project. I'm fine setting this up, but wasn't sure if you're already planning to do so in case you're planning to submit a pull request. I don't want to take credit for your work! :)

[nateabele]

@xiehan Thanks for clarifying, I'll spend some more time tinkering with it. A correct solution might be as simple as giving uiSref a priority.

[dlukez]

@xiehan - I'll leave it with @nateabele since he has a better idea of the best solution

[dlukez]

@nateabele How'd you go with this? I'd be happy to submit a pull request for review with the $timeout fix and updated unit tests if you like.

[xiehan]

@dlukez Just wanted to add that I forked the repo and applied your fix to the v0.2.0 release (https://github.com/xiehan/ui-router) so I could try it out in our production environment. Your fix works perfectly when I'm using the ui-sref directive; however, I am still experiencing the original problems if I use ng-href. It seems like the behavior for ng-href is the same, but the fix was only applied to cases where ui-sref is used instead. I looked through the code to find where the changes to ng-href might be made but I couldn't find it. For now it's no big deal, I can just switch to using ui-sref, but it'd be nice if they were consistent.

[phindmarsh]

@nateabele this commit seems to have introduced a problem when navigating between states. I've tried to make a plunkr to recreate the problem, but can't narrow it down (yet).

Anyway, after updating to this commit when I switched between states the template was displayed before angular had run $compile it (curly brackets and all that), then after a second or two it would render as normal. Coincidentally, I had an $http request that was returning in about the same time as the lag, so I thought it was waiting for that to finish before rendering the view properly. Note this was not in a resolve, just in the controller. Removing this actually made it worse, and I think I've narrowed down the problem to the $digest cycle.

It looks like this update means the navigation will happen outside angular's $digest loop, so the template is injected into the ui-view, but is uncompiled until something else calls $digest (in this case, the $http call was doing it). I managed to get it so it would never parse the template until I clicked something on the page and triggered a $digest.

A solution to this, which I'm not sure if it reverts the functionality you were attempting to fix above, is instead of scope.$evalAsync use $timeout with a scope.$apply. It also works if you put a scope.$apply after the $state.go call, but it throws one of those 'digest already in progress' errors.

The long and short of it is, before this commit, when navigating between states the compiled template was shown immediately, and now it shows uncompiled for a bit, then somewhere down the track it's properly compiled and renders correctly. This is with angular-1.2.2.

I'll keep working on trying to get a plunkr to show the problem, but after an hour or two I haven't nailed it down yet.

[nateabele]

@phindmarsh Interesting. Yeah, if you're able to put together a plunkr, that'd be super-helpful. Re: the $timeout() solution, I'll implement it if all else fails, but I'd prefer something less hacky if possible.