I want to allow something like the following to work in my application:
store.find('my-addon.my-addon-model', 1)
store.find('my-addon/my-addon-model', 1)
store.find('my-addon:my-addon-model', 1) (unlikely)
The thing is I want it to search for a model that is 100% defined in an addon.
import MyAddonModel from 'my-addon/models/my-addon-model' works from within my app - but container resolution doesn't...
How would I do/allow this?
This question is the same as:
Registering models from another namespace with the Ember Data store
However the naming there is a bit confusing. When trying this out I also seem to have hit a bug in ember-data#1.0.0-beta.15.
What you need to do in your module initializer is register the model(s) to your application.
import Ember from 'ember';
import MyModel from my-module/models/my-model';
export default {
name: 'my-module-models',
initialize: function(container, application) {
//one of these calls for each model you need to register
application.register('model:myModule.myModel',MyModel);
}
};
Now according to my experience with Ember and Ember-Data, this is supposed to work just like that. But in my setup with ember-data#1.0.0-beta.15 there seems to be an issue determining the models "key" after creation. The model instance is created fine, but you will hit an error trying to save the model.
I've found a quick workaround, but it's a hack and I would need to investigate further whether I'm missing a step or it's a bug. The workaround involves setting the "typeKey" of the class, resulting in:
import MyModel from my-module/models/my-model';
export default {
name: 'my-module-models',
initialize: function(container, application) {
//one of these calls for each model you need to register
application.register('model:myModule.myModel',MyModelreopenClass({typeKey:'myModule.myModel'}));
}
};
Finally, there is another way around. When creating modules in ember-cli, you have the app folder which will be merged with the app using your module. You could place default extends of your model(s) in the app folder.
Related
This is one of those Ember issues that I'm unable to replicate anywhere but my project. The visual effect of the problem is that the active class on a link-to is one transition behind. I'll click a link and the link that goes to the page I was just on is highlighted with the active class.
I've started digging into the link-to component code to figure out how active is computed. But it is based on _routing.currentState and I'm not sure what that is. The currentState, and other bits of info, are passed to the routing's isActiveForRoute which then calls the routerState's isActiveIntent. And that function calls another isActiveIntent and compares some more things together. All this seems like a large easter egg hunt for something (the root of my problem) that is probably not in Ember's code anyways.
I feel like the following snippet sums up the problem I'm having. The targetRouteName is the route that is being directed to by the link. _routing.currentRouteName seems to be pointing to the route the browser is currently looking at. The fact these match makes me feel like the link should be active, but the active function returns false.
> link.get('targetRouteName')
"parentRoute.pageA.index”
> link.get('_routing.currentRouteName')
"parentRoute.pageA.index”
> link.get('active')
false
For reference this is after finding the link via the Chrome extension and showing all components. I then did link = $E.
For the wrong link (the one that does get the active class) I get:
> link.get('targetRouteName')
"parentRoute.pageB.index"
> link.get('_routing.currentRouteName')
"parentRoute.pageA.index"
> link.get('active')
"active"
Additional Raw Information
The routes I'm dealing with are nested. But it is a pretty standard nesting, very much like the one I have in my ember-twiddle (e.g. page-a, page-b, page-c).
There is a model hook on the parent route and on the indexs of the children routes. But the children routes reference (this.modelFor(...)) the parent.
My template is referencing the .index of those routes. They are standard link-to components. They do not include model information.
I'm running Ember-cli 1.13.8, Ember 2.0.0, and Ember Data 2.0.0-beta.1.
What I have tried so far
Upgrading to 1.13.0
Moving the file structure to pods
Removing the functions in my authentication route which a lot of these routes inherit from.
Upgrading to 2.0.0
Trying to remove/add .index on my routes
Tried replicating on ember-twiddle
Doing ember init with ember-cli to see if my router or application setup was different from the standard layout and it doesn't differ in any significant way.
Adding model information to one of the links, that didn't change anything and since it didn't call the model hooks it messed up the view.
Asked on the slack channel
Please Help
I've had this issue for a couple weeks now and I'm not sure where else to look. I'd love any suggestions on how I can resolve this.
Update
This ended up getting fixed in 2.1.0.
This is common problem when you mess around with willTransition router action. For example,
IMS.ResultDetailsEditRoute = Ember.Route.extend({
actions: {
willTransition: function() {
this.controller.clearForm();
}
}
});
In this code snipped willTransition called controller's method "clearForm()" which no longer exists. For some reason, Ember doesn't throw an error, but it causes the problem that #RyanJM explained.
I have run into something similar when using a component with a nav. Here was my approach:
I added a controller (I know, you should be steering away form these, but I needed to). My controller:
import Ember from 'ember';
const {
Controller,
inject
} = Ember;
export default Controller.extend({
application: inject.controller(),
});
Then, in my template, I could pass application to my component.
{{account/account-icon-nav currentRouteName=application.currentRouteName}}
In my component, I set set up a function to test my current route names:
import Ember from 'ember';
const {
Component,
computed,
get
} = Ember;
const activeParentRoute = function(dependentKey, parentRouteName) {
return computed(dependentKey, {
get() {
return get(this, dependentKey).indexOf(parentRouteName) > -1;
}
});
};
export default Component.extend({
isYourProfile: activeParentRoute('currentRouteName', 'account.your-profile'),
isYourActivity: activeParentRoute('currentRouteName', 'account.your-activity'),
isYourGoals: activeParentRoute('currentRouteName', 'account.your-goals')
});
Then bind the active class yourself:
<div class="icon-nav md-hidden">
{{link-to "" "account.your-profile" classBinding=":profile isYourProfile:active" title="Your Life"}}
{{link-to "" "account.your-activity" classBinding=":activity isYourActivity:active" title="Your Money"}}
{{link-to "" "account.your-goals" classBinding=":goals isYourGoals:active" title="Your Goals"}}
</div>
I know this is a bit different since we are doing it within a component, but I hope it helps. You can bind these classes yourself by passing the application around.
What is the correct way of placing your helper files and also where should they go with respect to the resolver finding them from an addon ember-cli project?
I am running ember-cli 0.2.2.
I generated an helper from an addon project with:
ember g helper display-helper
The generator placed the file in app/helpers which seemed wrong to me, I would have thought that it should have been placed in addon helpers. I moved the file to addon/helpers and it looks like this:
export default Ember.Handlebars.registerBoundHelper('displayHelper', function displayHelper(searchPath) {
return new Ember.Handlebars.SafeString(get(this, searchPath));
});
When I ran ember test I get the following output:
✘ Error: Assertion Failed: A helper named 'displayHelper' could not be
found
The only way I get this helper to be found by the resolver is to add an import that references the helper in a component that is using it like this:
import displayHelper from '../helpers/display-helper';
This does not seem correct, I would have thought the resolver would have found this automatically?
Also even if I have the reference, the following code ends up with the same error message as above:
import Ember from 'ember';
var get = Ember.get;
function displayHelper(context, searchPath) {
return new Ember.Handlebars.SafeString(get(context, searchPath));
}
export default Ember.Handlebars.makeBoundHelper(displayHelper);
So to sum up, I have to have this line in the component whose template uses the helper:
import displayHelper from '../helpers/display-helper';
And I have to use registerBoundHelper and not makeBoundHelper like the docs say or the helper cannot be found.
If you move your helper from app/helpers to addon/helpers, it is not available in your app namespace. To fix this, add the following file:
// app/helpers/display-helper.js
import displayHelper from 'your-addon-name/helpers/display-helper";
export default displayHelper;
(Do not copy your-addon-name literally, use the name of your addon, which is also your addon's namespace.)
This is based on the instructions here:
http://www.ember-cli.com/#addon-components
Just like the example component there, you can put your real helper code in addons/helpers/display-helper, but you need to import and reexport it to your app for your resolver to find it.
I try to make an addon using ember-cli. Here it is step by step what I have done so far:
sudo ember addon test-addon
cd test-addon
sudo ember serve
now the server runs and on localhost:4200 I can see the test/dummy app's application hbs.
Welcome to Ember.js
Its time to make some components for the addon:
sudo ember g component my-form
In the tests/dummy/app/templates/application.hbs I added
{{my-form}}
And now I'm getting the following js error:
Uncaught Error: Could not find module test-addon/components/my-form imported from dummy/components/my-form
edit
After struggling a little bit with npm, I tried it again (without sudo) and the same thing happened. I'm on Ember CLI 0.2.1. Here are my files, but they should be the same since they are auto-generated. The error is thrown from bower-components/loader.js/loader.js line 110.
addon/components/my-form.js
import Ember from 'ember';
import layout from '../templates/components/my-form';
export default Ember.Component.extend({
layout: layout
});
addon/templates/components/my-form.hbs
{{yield}}
app/components/my-form.js
import myForm from 'test-addon/components/my-form';
export default myForm;
It looks like (as of July 2015, anyway) that the fact templates don't work in addons is partially by design. Philosophically, I guess the justification is that the styling should be app-specific, but the JS logic can be shared. Or it's just a bug/oversight.
It turns out that if you simply remove that layout line and the import layout, it will work.
So the result looks like:
<app-name>/app/templates/includes-a-shared-component.hbs:
What follows is my shared component! {{my-shared-component}}
<addon-name>/addon/components/my-shared-component.js:
import Ember from 'ember';
export default Ember.Component.extend({
valueFromProperty:function() { // simple hello-world-style function
return 5;
}.property()
});
<app-name>/app/templates/components/my-shared-component.hbs:
Hey look I'm the app-specific style for your component <marquee>Hello world</marquee>
Here's a value from a property: {{valueFromProperty}}
My versions:
Ember: 1.13.1
node: 0.12.0
npm: 2.12.1
And here's a very different (and IMO better, but not perfect) answer than my earlier one.
<addon-name>addon/components/test-component.js:
import Ember from 'ember';
export default Ember.Component.extend({
valueFromProperty:function() {
return 5;
}.property(),
layout:Ember.HTMLBars.compile("I'm the addon's layout {{valueFromProperty}}")
});
You will need to add the template compiler to your app:
<app-name>/app/ember-cli-build.js:
/* global require, module */
var EmberApp = require('ember-cli/lib/broccoli/ember-app');
module.exports = function(defaults) {
var app = new EmberApp(defaults, {
// Add options here
});
app.import('bower_components/ember/ember-template-compiler.js');
... other stuff...
Note that the layout property in the addon's component completely overrides your in-app template, so per-app customizing becomes more difficult. But if you want your template customizable, you could probably use my other answer where you don't specify layout at all and just let the resolver find the template in your app.
One more approach I've found that works and is different than my other answers.
Let's say you've done ember g component my-addon-component in your addon.
This will result in you having a component at: <addon-name>/addon/components/my-addon-component.js and a template at <addon-name>/addon/templates/my-addon-component.hbs (at least with my current ember-cli).
You'll also have a tiny component stub at <addon-name>/app/components/my-addon-component.js
The fix:
1. Move the component guts from <addon-name>/addon/components to <addon-name>/app/components (replacing the stub).
2. Move the template from <addon-name>/addon/templates/components to <addon-name/app/templates/components
After 1: The import layout from ../templates/components/my-addon-component will now have a different meaning: it'll be importing from the including-app's namespace instead of the addon's namespace.
After 2: The template's import location will be in the including-app's namespace. This also seems to mean it gets compiled by the app, so you won't throw the "addon templates were detected, but there are no template compilers registered"
I have web app and Ember app in iframe. I want to import custom library from web app to ember app like global variable. Library look like object with function:
var helpers = {
helper1: function() {},
helper2: function() {}
};
Library working with sockets and will the same for both applications.
I wrote:
app.import("./../../../public/scripts/js-helpers.js"); //file located in web app
I can't access variable helpers in project and ember-cli copy folder public into their working folder. Sorry if question is stupid, I can't understand ember-cli import principles.
I'll propose one solution, which I find to be the easiest. You won't have globally scoped variables, but you use then ES6 module approach.
For example purposes, let's say you have a file under app_name/lib/ called helper.js. lib is a directory you create for holding your custom libraries. You don't have to use that name. Use the export default command as such:
export default {
helper1: function() {},
helper2: function() {}
};
Then, lets say you need this in a route. Here could be one such route:
import helper from 'app_name/lib/helper';
export default Ember.Route.extend({
model: function(){
helper.helper1();
}
helper is the name of what you imported, and represents the object that you exported in your helper.js. This method seems to be the style in which Ember-CLI suggests you should use
as I mentioned in several questions here I am migrating an already existing and running Ember project to use Ember App Kit and I ran into several problems... here's another "problem" which wasn't a problem before :)
I've got a NotificationCollectionController which is placed under app/controllers/notification/collection.js.
file 'app/controllers/notification/collection.js':
export default Ember.ArrayController.extend({
addNotification: function (options) {
// some code
},
notifyOnDOMRemove: function (notification) {
this.removeObject(notification);
}
});
As this is the controller for notifications which are rendered through a named outlet I didn't declare a route for it.
Within my ApplicationRoute I want to access this controller within a function
file: 'app/routes/application.js'
import BaseRoute from 'appkit/routes/base';
export default BaseRoute.extend({
addGlobalNotificationCollection: function () {
var controller = this.controllerFor('notificationCollection');
// some more code...
}
});
But as soon as the application starts and this piece of code gets called I traced down the following error:
"Assertion Failed: The controller named 'notificationCollection' could
not be found. Make sure that this route exists and has already been
entered at least once. If you are accessing a controller not
associated with a route, make sure the controller class is explicitly
defined."
What does it mean and why is it thrown? What do I have to do to make it run again?
I didn't recognize that the hint is already given at the Naming Conventions section of the Ember App Kit Webpage:
It says, that the naming convention for a Controller is, for example: stop-watch.js
And if it’s a route controller, we can declare nested/child controllers like such:
app/controllers/test/index.js
So I placed my NotifcationCollectionController in controllers/notification-collection.js and call it like Route#controllerFor('notification-collection') and everything works as expected :)