3 ms·
Zombie Code Apocalypse: I would love to help you identify what it is that caused that problem. I don't suspect that it is an issue with Ember itself, though not
by nathanhammond 13y ago
Zombie Code Apocalypse: I would love to help you identify what it is that caused that problem. I don't suspect that it is an issue with Ember itself, though note that the Ember resolver will load code when you store it in `App.Foo(Controller|View|Route|...)` if that code is "needed" (say, by visiting the Foo route). So, unless you commented out the entire declaration it is entirely possible for that code to execute.
Spontaneously Changing Values: What was the key that you were trying to set? On what type of object (Route, View, Controller, etc.)? There are indeed some special values and it might be something that Ember can warn you of in the console as well as be documented. I'll be glad to make some documentation changes that make this issue easier to catch if you can provide me reproduction.
Godlike Refactoring: I work on a team with a widely distributed level of skills. One of my favorite features of Ember (which both has and will continue to save me hundreds of hours) is the fact that even if you make a mess of something you can generally come back and clean it up one piece at a time. My metaphorical description of this is that "all of the crap is in nice neat little piles instead of spread on the walls."
JavaScript.next: In the next/current version of JS both of these warts should be possible to resolve using Modules and Object.defineProperties(). I firmly believe that your complaints are not centered around Ember (which I honestly believe is insulating you from the worst of it) but instead from flaws in a language that was literally designed and built in an incredibly short time (my recollection is "a week" but I can't find a source).
(Edited for clarity based upon mixonic's reply.)
- mightybyte 13y agoI posted a comment on my blog with more information.
- mixonic 13y agoJust a nit for accuracy, but the implication that "the Ember resolver will load code when you store it in App.Foo(Controller|View|Route|...)`" eagerly is not true. I believe the author use an HTML comment to comment out his usage and not a handlebars comment, so the code was still being run (just hidden behind html comments). But regardless, Ember will not load everything in the App. namespace blindly- it will wait until that item is required, then try to load it. This is your helpful Ember #protip for the day. :-p
- nathanhammond 13y agoI've edited it for clarity based upon my original comment. :) I actually rely on this behavior every day because the app I've built uses require.js to load values into the `App.` namespace dynamically. That being said, now that you mention it, it seems far more likely that the issue was HTML vs HBS commenting. As an aside, what is the default behavior going to be for HTML comments inside of HTMLBars templates? That seems like a really weird edge case to decide how to handle (for developers).
- mixonic 13y agoOh my man, you really need to dig into the resolver! You can avoid the App. namespace entirely if you already use modules. This is what Ember-App-Kit and Ember-App-Kit-Rails already do with ES6 modules, just transpiled to AMD internally. And yeah, I'm unsure of that the behavior will be in HTMLBars. I really hope it doesn't touch logic inside HTML comments- that would be quite nice.
- nathanhammond 13y agoWe started on this project using Ember 0.9.6 (though we've managed to keep up with HEAD) and much of our architecture is predicated on the toolchain choices we've made. Our first big task on our list after reaching feature-complete is to migrate to EAK, don't you worry. (We knew it was coming and adopted require to make it easier to migrate.)