May be a silly question, but can't seem to get this right. I have some actions that I'd like to share across two controllers, so I'd like to define them in a mixin and then include them in the controllers. My syntax matches what I've seen in the guides:
mixins/shared.js.coffee
Dashboard.Shared = Ember.Mixin.create
actions:
showTab: (tab) ->
//handle action here
controllers/messages/messages_contacts_show_controller.js.coffee
Dashboard.MessagesContactsShowController = Ember.ObjectController.extend Dashboard.Shared,
Upon loading the app, I have this error:
Uncaught Error: Assertion Failed: Expected hash or Mixin instance, got [object Undefined]
I'm not sure how to load this mixin before the controller since my files are separate (ref: what is the correct way to use coffeescript with ember´s Mixins?'ve tried importing it but keep getting "reserved word" errors from coffeescript.
import { Shared } from './mixins/shared'
and
import Shared from "./mixins/shared"
What's the proper way to get a mixin to load before the controllers it will be used in??
I'm using Ember 1.8.1
Assuming you require your JS files in some main App script, the problem is most likely that "MessagesContactsShowController" sorts before "Shared". When you require with a wildcard, the files are included in alpha order. You might try moving your Shared mixin to a different folder and then changing the order of your require statements so it is processed before MessagesContactsShowController
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.
I have an Ember Addon which I've put up at Github here:
https://github.com/lifegadget/ember-dictionary
It passes all its unit tests and in a non addon form it is working fine in one of my projects but I'd like to lift it out the project and be able to use it as an addon. Still I'm clearly missing a step in how to expose the two Ember classes. This can be seen in the dummy app which tries to create a very simple model like so:
import DS from 'ember-data';
import DictionaryModel from 'ember-dictionary';
export default DictionaryModel.extend({
foo: DS.attr('string')
});
Then when the route (tests/dummy/routes/index.js) tries to use the model I get the following error:
Error while processing route: index Cannot read property 'extend' of undefined TypeError: Cannot read property 'extend' of undefined
To me this feels like a ES6/namespacing issue but I'm not sure how to overcome it. I did try the following more explicit import statement:
import DictionaryModel from 'ember-dictionary/models/dictionary-model';
but the same error occurred. Any help would be greatly appreciated.
I have bumped into enough walls that I think I can at least partially answer my question but some questions still remain so I won't mark this answer correct with the hope that others may post a more complete answer.
The first distinction I realised I hadn't been making clear enough for myself was whether to target the Ember App's namespace or to target an independent namespace for the addon. Classes defined in the app directory of the addon will be available to any application which uses the Addon in it's own namespace. In contrast, classes in the addon directory will be namespaced to the addon's namespace.
I have seen a lot people define classes in the addon's app directory and then proxy it through to the addon directory with something like:
// addon/mixins/dictionary.js
import DictionaryMixin from 'ember-dictionary/mixins/dictionary';
export default DictionaryMixin;
Although I've seen this I am still having problems getting these external namespaced classes to work. I think there may be another step needed to add a index.js entry point for the addon and then export these classes there. In any event, I'll leave this area alone as I decided to get the internal namespaced solution working first.
My next problem in the internal namespaced solution was centered around the dummy application that gets built as part of the addon creation process. I wanted this dummy application to have a model which would use the Mixin I created in the addon and I thought I'd be able to refer to it as:
import DictionaryMixin from 'ember-dictionary/mixins/dictionary';
but this couldn't be resolved by the Dummy test application so I had to resort to:
import DictionaryMixin from '../mixins/dictionary';
Which I guess is appropriate considering that my "external namespaced solution" isn't working yet ... falling back to the internally namespaced solution was required.
So, I've been trying to qunit test an Ember controller, The problem is, The controller is inside a coffeeScript file, that contains multiple controllers.
Now, The ember testing guide says, In order to test a controller, I should use the 'moduleFor' helper like so:
moduleFor(fullName [, description [, callbacks]])
In my case, the full name is say: "CustomersIndexController" , But because it's included in "customers_controller.coffee" that in it self includes multiple controller, Testing it became problematic .
After an Endless digging online, I found out (Please correct me if I'm wrong) that the resolver cares only about the file name, not about the name that 'export default myModel' provides
To make it more clear, Here is my "customers_controller.coffee" :
`export { CustomersIndexController, CustomersItemController }`
CustomersIndexController = Ember.ArrayController.extend
#Code goes here ......
CustomerItemController = Ember.ObjectController.extend
#Code goes here .....
And here is the customers-controller-test.coffee file :
`import { test, moduleFor } from 'ember-qunit';`
moduleFor("controller:customers-index-controller", 'C Controller')
test "it's an App.Controller", -> ok(#subject())
I've tried all the ideas that my brain could produce...without any luck(changing the controller name from camelCase to dasherized, to absolute path, even tried importing customers_controller.coffee), But I keep getting:
Setup failed on it's a App.Controller: Attempting to register an unknown factory: `controller:customers-index-controller`
Any Help/Advice/Links are highly appreciated.
You should be able to defined it in lower camelCase.
moduleFor('controller:postsIndex', 'Posts Index Controller');
http://jsbin.com/ruhalota/1/edit
If you take a look at the documentation for the resolver with ember-cli, you'll see that it does indeed only care about the names of the files, and what is the default export of them: http://www.ember-cli.com/#using-modules
In your case, you'll need to split your controllers into multiple files, so the resolver can find and instantiate them properly. So, the two files would be:
app/controllers/customers/index.coffee
app/controllers/customers/item.coffee
This is all assuming you are using ember-cli. If you are still using ember-app-kit, you might need to adjust this slightly, but the same basic idea should apply.
I'm learning to work with Ember and Grunt precompiled HBS templates, but want to also run in a 'developer mode' where the the App will compile the HBS's at runtime, if it doesn't find them.
I've read about a few ways to go about this and am trying to do it with '$.ajax()' and 'Ember.Handlebars.compile(data)' where each template returned is added to the Ember.TEMPLATES array. This won't work off the file system, so I test it on a localhost tomcat where the Ember App is added to webapps/ROOT.
I'm working with a demo 'user admin' App I found online which uses a couple of components, helpers and 'generated controllers'. So the Templates compile OK, but there are problems with Helper registration, such as:
Handlebars error: Could not find property 'modal-box' on object (generated modal-demo controller).
...so after adding the Component Template to the Templates array, I try to register it by name:
if (templateName == 'components/modal-box') {
Ember.Handlebars.helper('modal-box', function(value, options) {
var escaped = Handlebars.Utils.escapeExpression(value);
return new Handlebars.SafeString(tmpl);
});
}
...but then I get this new error:
registerBoundHelper-generated helpers do not support use with Handlebars blocks.
"Template was precompiled with an older version of Handlebars than the current runtime."
This is all done in an 'App create ready' function which iterates a list of template names, which I'd like to further develop to where it reads the template file names dynamically. The Grunt process also compacts the CSS and concatenates the scripts, so I would want to work out a 'developer mode' process for these too. But right now I'm focused on the HBS Templates & Components.
I'm thinking this must be a FAQ so am wondering if the community has arrived at a best practice for this sort of runtime compile for development?
If not how can I resolve my issue with getting the component template helper generated controllers registered correctly?
They just need to be registered before the other templates are compiled.
Em.TEMPLATES["components/cow-dude"] = Ember.Handlebars.compile("I'm a cow");
App = Ember.Application.create();
http://emberjs.jsbin.com/apIRef/28/edit
Order of operations is important, if it compiles the other templates first, they will just assume cow-dude is a property on the model in context (which will probably be undefined) (http://emberjs.jsbin.com/apIRef/27/edit). That being said, if you are going to lazy load componenets/helpers, those need to be loaded before any of their dependencies (Ember handles this all for you when you just toss them all in at once).
Additionally it sounds like you are using two different versions of Handlebars, which is why it's giving you the Template was precompiled with an older version of Handlebars than the current runtime.
I wrote up a similar response to someone else that might be of use to you: Ember.js with external handlebars template
I am typically searching for answers here but I finlly gotten to the point where I can't find a good answer.
I am looking to build an ember app which only initially loads in the things that it needs just to start and open the main route. All other controllers, views, templates, etc. Would be loaded lazily when a specific route gets triggered.
I have found a good example of how to accomplIsh this here:
http://madhatted.com/2013/6/29/lazy-loading-with-ember
My main question is to determine what build tools out there support this theory of lazy loading application code? So far, I've seen that Brunch, Yeoman, and Ember App Kit seemed to minify and concatenate all the scripts and templates. I am very happy with minification but need those files separate. I have thought about just putting this code into the app/assets location so that it gets copied over without concat but it does not get minified.
Does anyone have a solution? Thanks!
You can do this with brunch by adding the following to your brunch config
files: {
javascripts: {
joinTo: {
'javascripts/app.js': /^app(\/|\\)(?!admin)/, // concat everything in app, except /app/admin
'javascripts/vendor.js': /^vendor/,
'javascripts/admin.js': /^app(\/|\\)admin/ // concat only /app/admin
}
}
}
Grunt (used in yeoman and ember app kit) is ridiculously flexible, so I'm sure you can set up the same thing there by diving into Gruntfile.js
The question was: "I am looking to build an ember app which only initially loads in the things that it needs just to start and open the main route. All other controllers, views, templates, etc. Would be loaded lazily when a specific route gets triggered.".
Ember expects to have anything it needs right there when the page gets loaded. I wouldn't be wrong, but lazy loading of routes doesn't seem to be a feature of Ember. Ember CLI is the same. It uses bundling and minification to reduce the overload. But everything should be there to make it work.
Instead, people like me would like to load things only when they are required.
When you try to implement lazy loading in Ember, everything should be represented by a module (file.js): a route, a module; a controller, a module; and so on.
You should follow a schema (like POD), to which apply a mechanism to find things where they are supposed to be.
Every module should know its dependencies. But some of them are very frequent (route, controller, template).
You should use a module loader for the browser. It can be requirejs or whatever you like. But ES6 is at the door. Let's think about that.
Many people use beforeModel hook to achieve a result. I did it, and it works, if you don't use link-to component. Otherwise everything crashes. Why? Because of href computed property. When a link-to has been inserted, an href is calculated for it. Because of that, Ember looks for the route where the link points to. If the route doesn't exist, one is created from route:basic.
A solution could be the preloading of all the routes represented by all link-tos inserted in the page. Too much expensive!
An integration to this answer can be found at Lazy loading route definitions in Ember.js
For an initial solution to lazy loading of routes organized in POD, have a look at https://github.com/ricottatosta/ember-wiz. It is an ES6 based approach, which relay on SystemJS as module loader.