Initializers are required automatically #242

twokul · 2014-04-02T22:11:16Z

Fixes #59

adds new initializers folder under app
loads initializers automatically
adds CHANGELOG entry

MajorBreakfast · 2014-04-02T22:15:29Z

blueprint/app/initializers.js

+Ember.keys(requirejs._eak_seen).filter(function(key) {
+  return (/initializers\//).test(key);
+}).forEach(function(moduleName) {
+  var module = require(moduleName, null, null, true).default;


Non ES5 browsers won't like .default

['default'] u say?

I think it should just require the files, and not use the exports directly. This allows an initializer to do anything that needs to be done before the application boots. An example of this might be to reopen a core class or something.

twokul · 2014-04-02T23:10:23Z

@fsmanuel that might an option. I know @MajorBreakfast is eager to wrap it in bower package. let's see what @stefanpenner thinks.

fsmanuel · 2014-04-02T23:16:20Z

@twokul @MajorBreakfast just this one file or a ember-cli-utils bower package including the loader and shims?

twokul · 2014-04-02T23:18:11Z

unsure. we haven't discussed it yet.

stefanpenner · 2014-04-02T23:19:05Z

blueprint/.jshintrc

@@ -9,7 +9,9 @@
    "DS": true,
    "$": true,
    "ENV": true,
-    "module": true
+    "module": true,
+    "requirejs": true,


requirejs and require should be considered bad-practice, we should not globally disable linting, rather if they are really needed an inline comment is appropriate.

twokul · 2014-04-03T01:26:31Z

@stefanpenner I put boot helper under utils. It doesn't feel right for it to be there. Thoughts?

stefanpenner · 2014-04-03T01:35:21Z

blueprint/app/index.html

@@ -17,7 +17,7 @@
  </head>
  <body>
    <script>
-      window.<%= namespace %> = require('<%= modulePrefix %>/app')['default'].create();
+      window.<%= namespace %> = require('<%= modulePrefix %>/utils/boot')['default']('<%= modulePrefix %>').create();


I think boot should return the application instance.

consider renaming to main

move to top-level within the module prefix '<%= modulePrefix %>/main'

MajorBreakfast · 2014-04-03T10:01:12Z

I created a dedicated issue for bower package discussion: #249

twokul · 2014-04-03T11:44:59Z

@stefanpenner +1/-1?

stefanpenner · 2014-04-03T13:18:58Z

blueprint/app/main.js

+    return initializersRegExp.test(key);
+  }).forEach(function(moduleName) {
+    var module = require(moduleName, null, null, true)['default'];
+    if (module) {


if there is no module, we should throw and error.

stefanpenner · 2014-04-03T13:19:42Z

left one comment, once that is addressed then I'm +1

Good job!

Fixes #59

twokul · 2014-04-03T13:34:50Z

@stefanpenner done.

Initializers are required automatically

stefanpenner · 2014-04-03T13:36:20Z

thanks!

twokul · 2014-04-03T13:38:45Z

🎉

zonak · 2014-04-03T20:07:43Z

I tried this by placing an initializer in:

app/initializers

but it didn't work. Am I using a wrong location? I tried checking things out and noticed some new main reference so not sure if I have the right location.

Also on a related note, what is the recommended approach on loading mixins?

zonak · 2014-04-03T20:15:26Z

OK, some more input. I was trying the new feature on an already initialized app.

Starting a new app worked fine - what do we need to update for an existing project and for future reference would there be something like ember update that would address cases like this?

twokul · 2014-04-03T20:15:35Z

@zonak the example of initializer:

// app/initializers/my-fancy.js
export default {
  name: 'my-fancy-initializer',
  initialize: function() {
    // do things here
  }
}

I should have provided some examples. Once we have github pages up and running, it will be documented there.

Let me know if it fixes it for you.

zonak · 2014-04-03T20:16:38Z

That is the exact format I used - but something else is the issue. Please see previous two comments.

twokul · 2014-04-03T20:16:45Z

@zonak

Also on a related note, what is the recommended approach on loading mixins?

I would say drop them under app/mixins and then import them when you need it.

twokul · 2014-04-03T20:20:50Z

@zonak main is something that was introduced to support initializers. Take a look here. In order for autoload to work, you will need to have it in place. Long story short, you need to update the project.

It's our intention to have ember update in place so upgrading is painless for developers. Right now, we still defining the API. Stay tuned.

zonak · 2014-04-03T20:25:54Z

Thank for your help ... I was comparing existing files and missed that I need to add the new main.js file. Adding the file and updating the global in index.html fixed things.
Works great now.

twokul · 2014-04-03T20:44:32Z

@zonak 👍

bcardarella · 2014-04-05T02:05:40Z

blueprint/app/main.js

+/* global requirejs, require */
+
+export default function bootApp(prefix, attributes) {
+  var App                = require(prefix + '/app')['default'];


I think there should be a discussion if the app directory in ember-cli is strictly for business concerns or not. If it is (similar to Rails) then initializers should not be in the app directory. They would be a configuration concern.

as-is the app/ directory now has 10 directories in it. Things are getting crowded there. (I don't know why stylesheets are in the app directory but I guess that is another conversation)

You're raising valid concerns. We got it in to make developer's life somewhat easier and just to take it for a spin to see how it feels. There's a lot of things to discuss around configuration (what suppose to be where, what to expose, etc.). It will be one of the things on the roadmap.

something else to add to the constraints of folder layout, is to have other folders of lazy loadable bundles

Currently the thinking is:

app/ everything for your app itself

config/ build time configuration depending on the environment

tests/ unit and acceptance tests to make sure the app works

public/ files copied 1:1

I personally like the inititializers being in the app/ folder because they're doing runtime configuration of app instances (not build time).

If we want to spilt propose a spilt of js and non js stuff. (That's currently just styles/, though)

stefanpenner · 2014-04-05T13:59:38Z

@MajorBreakfast so given the "bundles" idea, what would our dir structure look like.

Please note, I am not saying we need to add this today, I just want it added to the constraints as we move things around.

idea: with the cli + some fixes to router + namespaces, we can make lazy loading of website sections nearly automatic by convention.

maybe:

app/ everything for your app itself
config/ build time configuration depending on the environment
tests/ unit and acceptance tests to make sure the app works
public/ files copied 1:1
bundles/ (optional) root directory of lazy loadable bundles

constraints:

bundles do not contain the router, likely will not (at first) have initializers, but in theory can contain anything else. If we by convention put them in a bundles dir, our brocfil can "know" what todo.

Also, they will likely additional more css/images/fonts

bundles/settings/
bundles/settings/controller/user.js
bundles/settings/route/user.js
bundles/settings/template/uses.hbs
bundles/settings/public/* this are for the setting specific assets, they will likely get exist @ /settings/* path
tests? (would be great if bundles could provide there own tests)

MajorBreakfast · 2014-04-05T18:36:59Z

@stefanpenner Never heard of the bundles idea before. Did you just invent it? :D Anyway I think that it could address one of the points of criticism ember has currently. Maybe you should open a discussion for that. Also we might be able to find a unified structure for addons and the app project itself.

stefanpenner · 2014-04-05T22:21:27Z

@MajorBreakfast its been in discussion for some time, but these discussions have not really been publicized.

fsmanuel · 2014-04-06T10:27:52Z

@twokul @stefanpenner love the new feature copied the main.js in my EAK project and got rid of all my overload files! thanks!

stefanpenner · 2014-04-06T12:01:52Z

A pr to eak would also be accepted. (For the interim)

MajorBreakfast · 2014-04-06T12:18:09Z

Yah, in EAK we made it work. In ember-cli we make it nice, too.

fsmanuel · 2014-04-06T13:01:46Z

@MajorBreakfast quite the opposite but here we go @stefanpenner

MajorBreakfast reviewed Apr 2, 2014
View reviewed changes

stefanpenner reviewed Apr 2, 2014
View reviewed changes

stefanpenner reviewed Apr 3, 2014
View reviewed changes

Initializers are required automatically

8397493

Fixes #59

stefanpenner added a commit that referenced this pull request Apr 3, 2014

Merge pull request #242 from twokul/ember-initializers

f255c42

Initializers are required automatically

stefanpenner merged commit f255c42 into ember-cli:master Apr 3, 2014

twokul deleted the ember-initializers branch April 3, 2014 13:36

bcardarella reviewed Apr 5, 2014
View reviewed changes

fsmanuel mentioned this pull request Apr 6, 2014

enables initializer autoloading stefanpenner/ember-app-kit#579

Merged

Initializers are required automatically #242

Initializers are required automatically #242

Conversation

twokul commented Apr 2, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

twokul commented Apr 2, 2014

fsmanuel commented Apr 2, 2014

twokul commented Apr 2, 2014

Choose a reason for hiding this comment

twokul commented Apr 3, 2014

Choose a reason for hiding this comment

MajorBreakfast commented Apr 3, 2014

twokul commented Apr 3, 2014

Choose a reason for hiding this comment

stefanpenner commented Apr 3, 2014

twokul commented Apr 3, 2014

stefanpenner commented Apr 3, 2014

twokul commented Apr 3, 2014

zonak commented Apr 3, 2014

zonak commented Apr 3, 2014

twokul commented Apr 3, 2014

zonak commented Apr 3, 2014

twokul commented Apr 3, 2014

twokul commented Apr 3, 2014

zonak commented Apr 3, 2014

twokul commented Apr 3, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanpenner commented Apr 5, 2014

MajorBreakfast commented Apr 5, 2014

stefanpenner commented Apr 5, 2014

fsmanuel commented Apr 6, 2014

stefanpenner commented Apr 6, 2014

MajorBreakfast commented Apr 6, 2014

fsmanuel commented Apr 6, 2014