Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Main use cases? #194

Closed
fullofcaffeine opened this issue Aug 5, 2015 · 1 comment
Closed

Main use cases? #194

fullofcaffeine opened this issue Aug 5, 2015 · 1 comment
Labels

Comments

@fullofcaffeine
Copy link

This is also related to my other issue/question here: #193

After trying ember-cli-rails for a while, I couldn't avoid to ask myself what are its main benefits/use cases? It's not clear to me, yet.

The README says:

You should still be able leverage the asset pipeline, and all the conveniences that Rails offers.

But you can't really use the assets pipeline from within the Ember app. For instance, you can't add a .slim extension to an Ember Handlebars template (.hbs.slim) and then use helpers like image_path to properly refer to images handled by the Rails' assets pipeline.

I tried adding the Ember app folder to the precompile list, but there are two problems:

  1. It takes a hell lot of time for Sprockets to process all the files in the uncompiled Ember app;
  2. Even if Sprockets compiles files inside the uncompiled Ember app, ember-cli-rails will run ember-cli before Sprockets, so it doesn't really make sense to do so, without hacking it further.

The README also doesn't make it clear what is the suggested approach for handling assets. Given that ember-cli offers its own assets pipeline solution, should it be used instead of Rails'?

For instance, with Angular, I made the decision to make Rails the "owner" of the app, and package the angular app within the Rails app (I think that's what ember-rails does, btw). I used this gem https://github.com/pitr/angular-rails-templates, and I could then use Slim templates which would then be converted to plain HTML through Sprockets. Very convenient and worked great. However, it looks like ember-cli-rails doesn't offer a way, by default, to precompile templates using the Rails pipeline, not even from EmblemJS (you can however, just use ember-cli with EmblemJS, but then, what's the point of using ember-cli-rails?)

What also added to my confusion was this post from the ember-cli-rails author, here :#30, quoting him:

I'd suggest using EmberCLI for javascript only for now, and use conventional Rails Assets Pipeline for stylesheets and other assets including images.

But how am I supposed to use the Rails assets pipeline with ember-cli?

The only benefit I see from using it is a portion of the Rails app is completely static or made with a different framework, and part of it is Ember, but the whole Ember app(s) has its assets completely handled by ember-cli. The additional benefit is to have the deployment handled by the Rails assets pipeline (namely copying the compiled ember-cli files to public/assets and fingerprinting them).

However, for a greenfield app, if one wants to go the ember-cli way, then I get the feeling it's much better to just treat Rails as an API and not attempt to integrate ember-cli with Rails, as it looks like it doesn't really make much sense because of the fact ember-cli duplicates a lot of functionality that Rails provides and sometimes they even conflict and don't play well together. Am I right?

If someone could enlighten me, I'd be very grateful!

@seanpdoyle
Copy link
Contributor

@fullofcaffeine Hey there, sorry this sat unanswered for so long.

About three weeks ago (October 23rd, 2015) thoughtbot inherited this repository, and I became a more active maintainer.

In that time, a lot has changed about the project.

We were able to resolve some problems around loading front end assets (an issue that stayed open for almost an entire year).

We've been able to let EmberCLI manage its own assets, while still integrating with the Asset pipeline

We've been able to make routing requests to an Ember app a lot easier.

We've been able to resolve some potentially show-stopping developer-experience issues, which required making some upstream patches to EmberCLI.

We've made integrating with Rails' CSRF protection totally transparent and automatic.

We've even streamlined and optimized deploying to Heroku with a single git push (a process that was previously bug-ridden and unimaginably slow).

Unfortunately, we don't currently (and probably won't support) hooking directly into the Asset pipeline to allow for Rails' compilation of EmberCLI templates with .slim extensions, (although there are alternatives).

However, given our new approach on rendering the EmberCLI-generated index.html, there's nothing stopping you from injecting your own stylesheets, javascripts, or images into your <head> or <body> tags with head.append or body.append blocks.

TL;DR:

Yes, ember-cli-rails has had some problems in the past.

Yes, we've resolved some of them.

No, we haven't resolved them all, and we've even punted on a few.

Either way, we're releasing the 0.5.x series in the next few days, and we feel that it'll be the best version yet.

Hopefully you'll agree and give the gem another shot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants