Since the Ember App Kit uses ES6 modules, I'm a little confused on the best place to put code that extends or configures base classes. For example the following code which enables using html5 history for hashless URLs:
//enable HTML5
Router.reopen({ location: 'history' });
Or the following code that provides a afterRender hook to all views:
Ember.View.reopen({
didInsertElement : function() {
this._super();
Ember.run.scheduleOnce('afterRender', this, this.didRenderElement);
}
});
From my understanding after reading issues on the Ember App Kit's github as well as from various answers on stackoverflow, it's ideal for ES6 modules to export only and not contain any "side-effects", or in other words, code that is not part of the exported object. However, it seems that the side effects technique is currently in use and even suggested by a number of developers. For example, I've put the html5 history configuration in my router.js module:
/**
* Ember Router
*
* @module Router
* @exports appkit/Router
*/
var Router = Ember.Router.extend({});
//enable HTML5
Router.reopen({ location: 'history' });
Router.map(function() {
this.route('login');
this.route('logout');
this.route('dashboard');
this.route('orders');
this.route('customers');
});
export default Router;
You can see that the module exports the Router object, but the reopen statement is just loosely sitting in the file.
To keeps things organized and take advantage of the technique, I suppose I could create a config folder, and then create modules inside the folder like view.js, router.js, etc:
view.js
/**
* Ember ViewConfig
*
* @module ViewConfig
* @exports appkit/ViewConfig
*/
Ember.View.reopen({
didInsertElement : function() {
this._super();
Ember.run.scheduleOnce('afterRender', this, this.didRenderElement);
}
});
export default {};
app.js
/*
* Config Classes
*/
import ViewConfig from 'appkit/config/view';
import RouterConfig from 'appkit/config/router';
...
This works, but I feel like I'm breaking a convention. Does this make sense or am I missing something?
Edit: I suppose another solution would be to export an object with a function, such as applyConfig and then after importing in the App.js call that function. But that doesn't address the fact that I'd still be using "side-effects" in App.js itself.
Since this got upvoted recently I wanted to provide an answer that I received from one of the authors (stefanpenner) of the Ember App Kit. You can read the discussion here: https://github.com/stefanpenner/ember-app-kit/issues/485
Basically I was on the right path, instead of a config
folder, he suggested to use an ext
folder and import in app.js
. The "side effects" aren't a big deal I guess. He did admit though that "This does feel some-what hacky" and he was open to suggestions...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With