[Proposal] Road to first class ES6 Modules support

[eccegordo]

I am aware of ember-appkit-rails https://github.com/dockyard/ember-appkit-rails but want to tease out some of the essential differences and see how ember-rails should/could move forward. And gauge what the current thinking is for everyone.

It may be that there should be a middle project between ember-appkit-rails and ember-rails to address some of the thinking below. But want to explore the viability of doing some of this work in ember-rails.

Below are some thoughts on what that might be. What the features and use cases might need to be.

Generate Ember App Kit stye ES6 syntax out of the box.

• bootstrap generator includes loader, jj-abrams resolver and es6 transpiler in project source
• generators produce es6 style code (export to default, etc)

This behavior should probably sit behind configuration flag to avoid breaking compatibility with existing projects that use Global variables for ember app.

Double MVC problem

Many existing rails apps are not greenfield, and therefore would like to ease gently into ember development. I think for many this means easily being able to have rails views and ember views live in harmony. Eschew some of the SPA bias. Provide some documentation and sensible configuration options that help with this.

• provide for bootstrap generator that enables the judicious use of rootElement option in Ember.Application.create()
• potentially get ember bootstrapping out of application.js and optionally configure for ember_application.js that can be selectively included on some subset of pages.
• Should we be working to bridge the divide between "document centric" page development and SPA application development? Fighting two concepts of routing can be a bit of a struggle for people new to ember. Old (server/client) habits die hard.

Portability of Ember Code and Code Generation

One of the great things about ES6 Modules is the way that they lend themselves to highly modular and portable code patterns. Easy to move bits of code around add a require import and boom ready to go.

I could image a common division of labor where pure client side work is done outside of a rails project (ember app kit and api stubs) and then easily included into rails project.

How might ember rails facilitate this work flow? Maybe a rake task that can analyze an EAK project and import code into rails project?

Integrate with future ember cli and ability to shell out to external tools for generation.

A more abstract concept of ember generators that work across tooling environments and workflows (node, rails, etc).

Multiple Ember Applications

Large preexisting rails apps might not easily be able to embrace the SPA concept.
A potential way to ameliorate this effort would be to have multiple "mini" ember applications within a larger rails project. Common backend models and rails generated json but multiple frontend modules that cover discrete areas of functionality within a large rails app space.

• Support for multiple "project" folders within the asset pipeline, each conforming to an EAK style project hierarchy

app/javascripts/
  ember-app-one/
  .../models
 .../templates
 .../routes
 .../controllers
 ... etc...

  ember-app-two/
  .../models
 .../templates
 .../routes
 .../controllers
 ... etc...

and so on

Maybe through configuration the generators can be project aware and an extra flag added that "just works" and puts the generated ember code in the right place.

Perhaps the up coming "pods" concept will help with this process.

For common functionality shared across projects (stuff like components) it seems like the ES6 modules approach will allow things to be very DRY when they need to be.

Thoughts? If this is way outside the scope of ember rails feel free to close issue.

[tboyko]

I'd greatly appreciate greater code portability between ember-cli created apps and ember-rails. The usage of ES6 in ember-cli is the most obvious difference I see between the two at this point.

[tricknotes]

I'm sorry for being late.

I supported ES6 module syntax by #416 .
I think this will work as your concern.

[tricknotes]

This is finished by #416