Better explanation of "ReferenceError: SYMBOL_ITERATOR is not defined" error

[jacobdr]

This is related to #9 (which was resolved) -- essentially it seems that the @Componenent annotation is calling out to jQuery but doing so using an anonymous function that doesn't really give a helpful stack trace.

For example, I get error messages like this in my console:

ReferenceError: SYMBOL_ITERATOR is not defined
    at checkIter (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:1090:7)
    at getCollection (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:1119:33)
    at Object.23../$ (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:1263:11)
    at s (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:40:254)
    at eval (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:40:305)
    at Object.1../src/es5 (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:55:1)
    at s (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:40:254)
    at e (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:40:425)
    at eval (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:40:443)
    at eval (eval at <anonymous> (http://localhost:50017/packages/jquery.js?dd8bac56f8fd3666d433d2285ae01e52597cc51a:372:22), <anonymous>:2263:2)

I was hoping that we could either try to work on improving the documentation around the @Component (for example, the different "bind" options of '=', '&', and '@' are not documented), and maybe also provide a more helpful error message when the "selector" fails (which I think is the origin of my error).

[pbastowski]

@jacobdr I'm open to documentation improvements. Perhaps you would like to help with a PR?

I have not documented the bind options "=", "@" and "&", because they are exactly the same as those documented here https://docs.angularjs.org/api/ng/service/$compile under the heading Directive Definition Object, sub heading scope. Perhaps we could add the link to the relevant AngularJS documentation.

Also, what do you mean when you say?

more helpful error message when the "selector" fails

Could you provide me an example of the actual problem or a link to a repo?

[jacobdr]

The work that you have done so far is really awesome -- and until the Angular2 docs get updated (they are really pretty sparse right now...) your project allows our team to experiment with the new syntax while being able to fall back on the old API without penalty.

I am very happy to help out. I am actually pretty new to Angular2 (and even Angular1), and so am reading through your source and trying to get more familiar with it. I forked the repo and will try to submit a PR in a couple of days when I feel more comfortable.

With regard to that error, I think it is related to the fact that I am mixing syntaxes in my project. For example, I am registering one controller via the Ang1 module("x").controller("y",function(){}) and a second controller via the new syntax. I don't use the bootstrap function since I already have an ng-app corresponding to those older modules at the top of my source.

I thought that I could just register a new controller using SetModule(), then use the @Component tag, and then drop in a corresponding "" tag in my index.html and everything would just work. Seems like I am running into slightly more trouble, which I think relates to the "selector" property in the @Component annotation, since it is jQuery that is showing up in that stack trace, but I could be totally wrong. Anyway, it would be ideal if that stack trace would mention the line in the Angular2 now file that is the root cause of the exception. At the end of the day I am fairly certain it is an error in my use of the library and not a bug, but descriptive errors are still a useful end to achieve.

At the end of the day this is all related to the fact that I am mixing syntaxes, and so was hoping you might have some examples pages or best practice suggestions for how to do this.

[jacobdr]

Of course my error was a typo in the @View{templateUrl:path}.... Not sure if you have any ideas for how to throw an error that would indicate as much, but I'll mull over the source and submit a PR if you think that it is appropriate

[pbastowski]

This error is a known issue with Angular-Meteor. You'd also get this error if you weren't using angular2-now and you mistyped the name/path of a template in a templateUrl. So, a typo in the template path results in some weird angular error, which doesn't seem to relate to anything. However, it is not actually to do with angular2-now.

The solution, as I see it, would be to verify that a template path actually exists. To do that you'd have to try to pull the template itself in using XHR ($http) or something similar. Also, the template could already be in the template cache, if your build workflow bundles your templates into JS files, like Angular-Meteor's does.

I might look into angular-meteor on the weekend, if I get some time, to see if I can find/fix this issue.

But the good news for now is that this is not an angular2-now bug :)

[pbastowski]

Regarding mixing normal code with angular2-now, the best advice I have is don't do it.

Also, try to not use stand alone controllers at all.

I have some examples listed at the top of the README, which show how to put together applications with my library. Perhaps those would help?

At work we are using angular2-now in production on some larger projects. I was thinking about extracting some best-practices from those, but there never seems to be enough time. Again, perhaps this weekend :)