Is there a way to get Ember to log a warning or error if you reference a property that doesn't exist? Currently if you misspell a the name of a property bound in your handlebar template there is no warning, it just doesn't show anything, and it can be hard to find which property is incorrect.
I have LOG_BINDINGS enabled, which helps somewhat, but there is a lot of unrelated stuff to sort through.
There isn't any sort of general built-in debugging that I have found, but there is a mechanism to add your own.
Ember.Object calls a method 'unknownProperty' any time a 'get' call returns undefined. You can add a console.warn to this method to log the property. The documentation describes it as a way to make custom abstract method type handling.
http://emberjs.com/api/classes/Ember.Observable.html#method_get
Ember.Object.reopen(
unknownProperty: (property) ->
unless property is 'App' or property is 'Ember'
console.warn "Unknown property #{property} in #{#toString()}"
)
Notice the filtering of the global namespaces 'App' and 'Ember' - all calls to global properties still go through this interface, but for what we care about they are red herrings.
Unfortunately, if you try to do this by reopening Ember.Object itself, you get a bunch of junk you don't care about, because apparently this happens all the time, especially in the EventManager classes. I have gotten around this by applying it to Ember.ArrayController, Ember.ObjectController, and a Model class that all of my models inherit from.
I now get a neat warning message on the console instead of a blank page every time I accidentally type "hight" into handlebars instead of "height"
In a production solution one would want to link this to some kind of "debug" option in the build, I assume.
One half solution might be to use the log handlebars helper to log the property before using it, unfortunately a non existent property causes the template to not display at all. This is a common problem with handlebars not displaying errors.
{{log myProperty}}
Related
I got the following error while developing our front-end with Ember.js:
ember Error: Compile Error: '...' is not a helper
What is the meaning of this error?
Reason
Ember throws this error if there is no component or helper with the given name is not found in your project or your dependent addons.
How to solve
You should check the name of the component or helper that you have written (possible errors are spelling errors or writing directory structure of the component incorrectly).
This twiddle shows example of this error message when the component my-component is called as {{my-component2 x=x}} instead of {{my-component x=x}} mistakenly.
This error can also happen in older (pre-Octane) versions of Ember if you have your component in all the right places, but your component doesn't have a dash in its name. As per the docs, components are required to have at least one dash in their names:
Components must have at least one dash in their name. So blog-post is an acceptable name, and so is audio-player-controls, but post is not. This prevents clashes with current or future HTML element names, aligns Ember components with the W3C Custom Elements spec, and ensures Ember detects the components automatically.
If you try to create a component without a dash in its name, Ember won't find it and will give you this error.
It appears this requirement has been lifted in more recent versions of Ember, where components start with a capital letter to distinguish them from native HTML elements.
From the documentation:
Helpers allow you to add additional functionality to your templates beyond what is included out-of-the-box in Ember. Helpers are most useful for transforming raw values from models and components into a format more appropriate for your users.
It looks like you are using a non-defined helper. So please look through (and maybe provide) some more of your log output. You are probably using an undefined helper in one (or multiple) of your .hbs-files.
component and file name must be the same. This solution worked for me.
The same is true for 'get' methods too. Like get(this, 'agentName') and this.get('agentName') returns the same value.
In the official ember doc for get method, it shows that we are supposed to pass 2 values to get. Then how does this.get('agentName') work accurately?
this.get(...) is a shortcut for Ember.get(this,...). However it is only available on ember objects, so only Ember.get works in plain js objects.
Have a look at this.get(...) implementation.
The getter and setter in Ember has been upgraded to handle unknown property, computed property and observers. Not many people would use setUnknownProperty() hook or the unknownProperty() hook with get and set, but there are computed properties and observers throughout most people's code. More on computed properties and observers.
So, the basic difference between your set() and this.set() has to do with the context of your function. When you call just set(), it has to be defined in that scope or imported from somewhere to get things done. Howeve, with this.set() the scope here is this. Depending on where you are calling the function the scope changes. For instance if you are in a component, this refers to the component class itself. Similar would be the case with controllers, routes and other ember objects. If you have object of your own and it does not extend any of ember classes, then this would still work with how it does in any other JavaScript code. So it will fall back to default getter and setter in JavaScript.
As you may have realized by now, when you call get(this, 'foo'), you are calling JavaScript's getter function and pass it the current context with property to be searched for. And when you say this.get('foo') you are calling get() from Ember.Object class, which can handle things I mentioned above. And as #Lux mentioned this.get('foo') is simplified to call Ember.get(this, 'foo').
Hope this helps. I do encourage reading Ember guides and API docs. Curent ember-cli and ember-data version is #2.12.0
I have created a mock application to illustrate the situation I am facing: Mock App
In this application; I have created a service with a single boolean property and a function to toggle that property (x); and two components (one to toggle the service's property; the other to observe the number of toggles and display it). The observer lies in toggle-observer. It is added directly to service's property as: myService.x. The code is not working as is; however if the comment at line 14 of toggle-observer.js is commented out; the observer starts working.
My question is that, do I need to perform a get to the whole path of a nested observer property to get it working? Is this the expected behavior? If so, can somebody explain why? My best regards.
Note: This is a mock example to illustrate the case; it is not related to anything I am designing in a real app. I am trying to avoid observers as much as possible; but I ran into this situation while trying out sth. and decided to ask it.
From ember guide service
Injected properties are lazy loaded; meaning the service will not be
instantiated until the property is explicitly called. Therefore you
need to access services in your component using the get function
otherwise you might get an undefined.
From ember guide, unconsumed computed properties do not trigger observers.
By combining the above two concepts, we can come to the below conclusion,
You haven't used myService any of the property inside toggle-observer component so it will be undefined until you explicitly call get function or use it in template.
Unless you use it x property in toggle-observer component, then it will not trigger observer. You need to consume it either in toggle-observer.hbs file or in init method.
As part of an attempt to port a fairly large/complex existing application to the Ember world, I'm generating and compiling named Handlebars templates dynamically, and associating views with them, using the technique:
var template = Ember.Handlebars.compile("some handlebars stuff");
Ember.TEMPLATES["myTemplate"] = template;
var view = Ember.View.create({
templateName: "myTemplate"
});
One of the things I'd like to do is be able to recompile new/different Handlebars template markup which overwrites the template named "myTemplate" and have it be accessible to views at that name.
I'm getting unexpected results trying to do this - a couple fiddles that illustrate the problems:
First fiddle - Shows what happens if you wait before rendering a view after the named template contents have changed.
Second fiddle - Shows what happens if there's no delay before rendering a view after the named template contents have changed.
There's obviously some magic under the hood that I'm not understanding. Can anyone shed some light on this?
UPDATE:
I went through the source code for Ember.View and the container module, and came to realize that I could solve the problem in the First fiddle by overriding the "template" computed property in a way that skips the container cache lookup. I've put up another fiddle here to demonstrate the solution I found.
This seems to be working the way I'd like it to - but - it feels like I might be fighting with the framework and "unhooking" from the container in a way that might bite me later. Is there a better, more Ember-esque way to accomplish what I'm trying to do? Will the hack I found break things?
UPDATE 2
I've also discovered that it's also possible to simply call
view2.get('container').reset();
before appending view2 in the First fiddle. Seems cleaner/safer, but is it "legal"? I've updated the First fiddle to illustrate this.
(in the second fiddle, both views show the second template)
This is because view1.appendTo($("#target")); just schedules the append, actual view rendering does not happen until end of the run loop. Before that happens, you've set Ember.TEMPLATES["myTemplate"] = template2;
(in the first fiddle, both views show the first template)
Pretty sure this is because ember container caches template fx, but not 100% on that. Checking...
I'm going to call this one answered. As I mentioned in my second comment, I'm using the solution shown in this fiddle in my project, along these lines:
mYiew.get('container').reset();
There's some discussion about the container not being intended to be used as an API here: https://github.com/emberjs/ember.js/commit/5becdc4467573f80a5c5dbb51d97c6b9239714a8 , but there doesn't seem to be any mention of using the container from Views for other use cases.
Also, a View's container can be accessed directly (at ".container") - meaning the devs haven't made it "hard" to get to the way they have for an Application's ".__ container __". This might suggest something about how they intend it to be used.
Since a View having the ability to clear its cache whenever it wants to doesn't seem to me to be unreasonable or a bad practice, I'm using the above mentioned solution...at least until someone sets me straight with a better idea (or a cache API).
I'm using Ember built from git master. My RouteManager is not complex, but when I try to start my app, I get this error:
Uncaught TypeError: Property '1' of object , is not a function
Following the trace indicates that this is happening on the app's initialization.
This jsfiddle shows the problem, although you'll have to look in the javascript console to see the error message. My actual router will be more complex than this, but I've pared it down to the bones to try to eliminate potential error sources.
You need to update your version of Ember Data to the latest version from master, as the injection API changed.
Here is a fiddle which "works".
http://fiddle.jshell.net/Sly7/ZySzK/
I pick up an ember-data resource from another fiddle I found on stackoverflow.
The way of populating the arraycontroller is weird. Usually you pass the context in the connectOutlet method of the controller, by specifying a context (in your case, it should be Sylvius.Section.find() )
I don't know why, but doing this, I have the error 'Sylvius.Section has no method find'... perhaps an other mess due to ember-data/emberjs bad version.