I'm wondering what the convention to use is when creating a component inside an addon project... If I generate a component in my addon project using ember-cli#0.2.0, the blueprint will create a js file in addon/components, a template in addon/templates/components, and a js file in app/components. The part I'm not real clear about is where templates should live for these components. If my component template requires a partial, I need to put the partial template in the app/templates directory. If it lives in the addon/templates directory, it can't be resolved. So the question is this: Is it best to put all the templates (the component template and the partials) in the app/templates directory or leave the component template in the addon/templates/components directory and the partial in the app/templates directory? The latter feels slightly disorganized and the former seems more correct only because of the behavior of the blueprint. Anyone have any insight?
Thanks in advance.
Ember-cli is under heavy development so a lot of the file structure is likely to change soon, but here on some insights on the current state of the folder structure and why it is arranged the way it is:
The app/ folder is what gets directly imported into your application. Helpers are pulled from here, which is why you have to have a file for each of your components in this folder. Additionally templates will get pulled from the main application here, and as such they will be accessible in the ways that templates are normally accessible in an ember app (render, partial, and standard resolution).
Some people choose to place all of their components code in app/, but this is a bad idea because the addon/ folder exists not only as a separation of your addons code, but as a way for it to be imported using ES6 imports. So, while you can't directly access the components under addon/components/, you can import them into your application like so:
import SomeComponent from 'some-addon/components/some-component'
This is very useful for addon consumers if they want to extend an addon to add some functionality.
Templates in addon get precompiled in the build tree, which makes addons a bit more robust (for instance if they are using a different version of htmlbars they will still be compatible with the base app). However, they are not accessible via the resolver, so you have to import them manually in your addon's components, which is why the blueprint for addon components looks like the following:
import Ember from 'ember';
import layout from '../templates/components/some-component';
export default Ember.Component.extend({
layout: layout
});
Styles for addons can either be placed in addon/styles/ or app/styles/. In addon/styles/ they are also precompiled and included in the application by default. I highly recommend including styles in app/styles because this makes them accessible using preprocessor imports in the base application:
#import some-addon/main.css
This makes them completely optional to users of the addon, without resorting to app.import and config trickery (which is good because nested addons _do not support app.import. Don't use it.)
NOTE: They are not automatically namespaced, so you should put your styles in a folder to make sure they aren't conflicting with other addons styles.
In summary:
Any addon code that does not need to be directly accessible by the base app via helpers, initializers, etc. Should live in addon/
Anything you want to be accessible by ES6 imports should live in addon/
Templates should live in addon/templates/ and be imported manually
Component stubs, initializers, and other files that should be included in the standard Ember build chain should live in app/
Styles should live in app/styles/ and should be namespaced in a folder (e.g. app/styles/some-addon/)
Don't use app.import.
Related
What I'm trying to do in Aurelia, is something like Prism is doing in WPF- Composite applications.
So lets say I have a "shell" application that defines the main application layout, then i have modules that I can plugin at run-time. Those modules can be an Aurelia application per se or Aurelia plugin (don't know what to use - need recommendation).
When loaded, the module needs to add it's menu items to the main application menu to expose it's features.
This is a mockup of the application:
Each module can have multiple menu items and can be pretty complex.
I'm using latest Typescript, Aurelia-CLI to create the application, and I'm using the built-in bundler : Aurelia's new built-in bundler.
So What I don't know is:
Those modules/features - what must they be? (Maybe Aurelia Plugins, or another Aurelia application?)
How to load those modules/features at run-time? (like deploy it in some plugins folder and tell the main shell application to load them)
How to modify the main menu and add new menu items from the loaded module?
Please help
Aurelia supports ultra dynamic applications. Also, there have been other community members who have had similar requirements and was able to resolve it. So I think the scenario is possible.
It seems the sub-application can just be a route.How/where to load the route should be determined based on the application URL
Those modules doesn't need to do anything specific, they can just be a normal, plain JS/TS class with lifecycle methods to handle activation/deactivation. I guess that main shell and all sub-applications need to share a common URL, you cannot have more than one router.
There could be a singleton/central store for new route to register information about loaded features, or it can be loaded upfront by a configuration file/metadata file or a database fetch.
Here is a similar question from another community member that I think can help you see how to glue things to https://discourse.aurelia.io/t/dynamicaly-load-routes/1906
I already worked with emberjs before it used ember-cli but now I am not sure how I can do that.
I need to create some functions to manage my cookies and some other thing, but I don't know where I should put them in the project so they will be available from anywhere (controller, routes, views...). I looked at the emberjs guide/doc but I can't find anything relevant about that unfortunatelly..
Is there is a specific place I can put my functions ? or I have to copy/paste them everywhere ?
Should I put my scripts inside the vendor folder ?
Thanks.
You can place it in a util script. To create one, type in ember generate util foo
Take note that it uses ES6 syntax with the export default and stuff.
Once you have the util script you can import it in your controller, route, etc.
I'm writing an addon that defines a StickyHeaderListComponent under addon, and import it according to the Components section of the addons section of the guides.
I'd like to write some tests + use the dummy app, but the dummy app doesn't have access to {{sticky-header-list}}. How can I import it?
The app folder is merged into the application which consumes the addon during the build.
So, The file sticky-header-list.js should be under app/components.
Best practice is to write a mixin which will include the entire code of the component under addon/mixins
// addon/mixins/sticky-header-list.js
export default Ember.Mixin.create({
//Put all the component code here
});
And the actual component will be
// app/components/sticky-header-list.js
import StickyHeaderListMixin from '<your-addon-name>/mixins/sticky-header-list';
export default Ember.Component.extend(StickyHeaderListMixin);
In that way, a developer that will install your addon can choose to use the mixin, since the component code is not available at dev time.
The mixin will be importable under the path <your-addon-name>/mixins/sticky-header-list.js.
You can see an example in my ember-cli-lightbox addon.
I'm not an experienced Javascript application developer, however, I've recently been learning some MEAN using http://mean.io/#!/ as my scaffolding.
I can see that the out of the box assets are listed in:
/server/config/assets.json
and when the app is running the referenced assets get combined into client side files:
/modules/aggregated.css
/modules/aggregated.js
When I create a package using MEAN.IO's CLI:
mean package myPackage;
and start including css or scripts in this package, presumably it is bad practice to then put the packages assets into the application's assets.json as these packages are supposed to be reusable modules that could be added to someone else's MEAN application.
What's the right place to reference the new package's assets so that they are added into the aggregration process?
you want to add css or js files into your packages.
If so, it's easy. As the doc says in "Assets and Aggregation" http://learn.mean.io/#mean-packages-assets-and-aggregation
you should use
//Adding another library - global by default is false
MyPackage.aggregateAsset('js','jquery.min.js', {global:true});
//Adding some css to the mean project
MyPackage.aggregateAsset('css','default.css');
I have created two separate add ons. One for getting input from the user and storing in simple-storage. In the other one the actual add on function. Both work fine. But when i merge these both main add on code in to a single main code they didn't work. So i wonder whether there can be two js files in "main" add on directory and is communication possible between them?I need one of the js in main directory to be able to access the simple-storage of the other js in the same main directory.
I'm really not sure what your overall goal is, please provide an example for a more specific answer. If you're using the Add-on SDK, only code in main.js will be run, but you can use commonJS modules to implement various features and use require to import them into main.js.
Please see the docs for more information on how the Add-on SDK works:
https://developer.mozilla.org/en-US/Add-ons/SDK