images and other assets

[samselikoff]

where should we put assets? I have an image in my ember cli app's public folder, but it's not showing up in the rails app.

[rwz]

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

[samselikoff]

hmmmmmmmmmmmmmm

[samselikoff]

what if I don't like the asset pipeline? 😛

There are many ember cli addons that bring in components with both js and css, how will these work?

[rwz]

`¯_(ツ)_/¯

Any suggestions?

We could investigate if it's possible to append public directories to Rails ActionDispatch::Static handler.

[rondale-sc]

you can use include_ember_stylesheet_tags and include_ember_script_tags. Addons will push the css they need into the files included by the former. (I think)

[rondale-sc]

As far as images are concerned, I'm not sure what to do here. If you just throw them into the rails app they'd be availble but you'd not have the asset helpers in ember land

[samselikoff]

right. ok I'll think more about this.

I tend to like the frontend/backend separation when doing ember/rails apps, so this rubs me a bit the wrong way. But so far I'm liking the integration.

I'll let you all know how it goes. Thanks for the work by the way, the project has a great api!

[rondale-sc]

Thanks! And thanks for tryin' it out. :))

[edit] Let us know if you have any thoughts on this btw. More eyes lookin' at it the better.

[rondale-sc]

@rwz Isn't the result of the build symlinked into the asset path of rails. If that is true then images should be served already. (will test as soon as I can, prolly not tonight)

[rwjblue]

I believe that we need to change https://github.com/rwz/ember-cli-rails/blob/dec085b0a67c3ff05367ccc6b7384d148f6df23a/lib/ember-cli/app.rb#L127 to just symlink dist_path.

Does that make sense?

[rwz]

Well, then the assets path's gonna be awkward, like "/assets/frontend/assets/frontend.js"

[rwjblue]

True, but things would work ;)

[rwjblue]

If you have an addon that adds things to the ember-cli its public tree, those assets will end up in dist/addon-name/whatever-file-name.foo. This is super useful if you want your addon to be able to lazily load assets.

For example: I have an addon that adds a rich-text-editor component using TinyMCE, obviously I do not want all of TinyMCE in my vendor.js (despite its name it isn't very tiny) so I have it in the public tree which ends up at dist/ember-cli-rich-text-editor/tiny-mce.js, then during the component's first initialization it ensures that asset is loaded. That way the consuming app doesn't need the asset to impact vendor.js size, and it only takes a hit on loading if you use the component.

It is also nice to have images in public/images/ and fonts in public/fonts/ (I realize that all of these could be done by Rails too).

tldr; I think more things from the EmberCLI world will work out of the box, if the all of dist/ were available....

[rwz]

Now, I don't think just changing symlink from "dist/assets" to just "dist" is gonna accomplish anything here. The reason is that your Ember component will expect TinyMCE to be available at /ember-cli-rich-text-editor/tiny-mce.js, but assets pipeline will be expecting /assets/frontend/ember-cli-rich-text-editor/tiny-mce.js which is different.

Alternative solution will be to keep assets pipeline the way it's now, but also attach dist folder as an alternative public path. So Rails will serve /ember-cli-rich-text-editor/tiny-mce.js the same way as if you put in public folder.

[rwjblue]

@rwz - Setting the EmberCLI baseURL to /assets/frontend/ in config/environment.js and everything works PERFECTLY....

This is one way that folks deploy to S3 for example (just set the baseURL to the final deployment path).

[rwjblue]

The baseURL could likely be set by the addon (and the path would be provided via an ENV var like the new SUPPRESS_JQUERY thing we added) so everything "just works" magically (who doesn't like magic?).

[rwz]

What do you think of my mount-dist-to-public idea?

[rwjblue]

Ya, mounting dist to public should be fine (and might also help the deployment situation). But if we do this, then why do we need to do both things (symlink dist/assets/ into tmp/ember-cli-rails-asdfasdf and dist/ to public/frontend/)? Also, we should still update the addon to set the baseURL to where the assets will end up at...

[chrisdevor]

I created PR #56 that may be worth looking at regarding this issue. It basically copies the contents of dist/assets into public/assets and then updates manifest.json to reference the correct fingerprinted files for app_name.js, app_name.css, vendor.js and vendor.css. Thoughts?

[rondale-sc]

@chrisdevor I'm going to try to take some time tomorrow to look at #56 more closely. :)

[chrisdevor]

Sounds good. It should work with a stand alone rails s environment or rails s in combination with ember s --proxy:http://0.0.0.0:3000 (@ localhost:4200). Let me know if you have any questions or issues.

[chrisdevor]

Looks like broccoli-asset-rev has a built in generateRailsManifest option that I overlooked. I'm going to investigate using that and probably push a few more fixes/updates on that branch I made over the weekend.

[TeknoFiend]

Seems like setting baseURL would not be the right thing to do since that has other effects, no?

[ljuti]

Any advice on how to use generateRailsManifest or other means to get assets into production. I have assets, such as images, in my Rails asset pipeline that I'd like to use in Ember templates. Assets are compiled properly, but templates do not have fingerprinted URLs to them.

[obuchtala]

Just want to contribute a problem scenario which we are facing currently.
Unfortunately I am not experienced enough in ember-cli(-rails) to contribute to a solution.

We are using the font-awesome addon: https://github.com/lfridael/ember-cli-font-awesome
It adds its assets to "/fonts" https://github.com/lfridael/ember-cli-font-awesome/blob/master/index.js#L21-L27
But eventually these are not available in the rails app.
Any advice welcome, thanks!

[rainkinz]

I had the same issue and ended up copying the fonts dir into app/assets/stylesheets. It works, but I'm sure it's not the recommended solution.

[obuchtala]

@rainkinz ah, interesting fix for this particular problem. Thx.

[gniquil]

I have a hack, kind of works and would like to know if this is ok.

First, in a helper for the Rails app say app/helpers/application_helpers, I have

module ApplicationHelper
  def image_assets
    image_asset_dir = Rails.root.join('app', 'assets', 'images')

    assets = {}

    %w(.jpg .png .jpeg).each do |file_ext|
      Dir.glob(File.join(image_asset_dir, "**", "*#{file_ext}")).each do |absolute_path|
        file = absolute_path.sub(File.join(image_asset_dir, '/'), '')
        assets[file] = asset_url(file)
      end
    end

    assets
  end
end

with this defined, create this file app/assets/javascripts/assets.js.erb with the following content

<% environment.context_class.instance_eval { include ApplicationHelper } %>

window.assets = window.assets || {};

window.assets.images = <%= raw(image_assets.to_json) %>;

now, assuming you have the normal frontend.html.erb file, just do the usual:

<%= javascript_include_tag 'assets' %>

Once you do this, you will have access to window.assets.images in the environment. From here it's easy to wrap this in an Ember helper say rails-asset-url and use it like

{{rails-asset-url 'logo.png'}}

Since all the assets are in a .js.erb file, it is precompiled so the Dir.glob should have no impact in production. If this works, I think it shouldn't be too hard to roll into ember-cli-rails. :)

What do you think?

[Samsinite]

Sweet! Thanks @seanpdoyle I'll test locally, then in a staging env and let you know how it goes.

[seanpdoyle]

@Samsinite (and anyone else waiting on a fix):

Any success with #30 (comment)?

[skylar]

@seanpdoyle thanks. i haven't had a chance to check it out, but it looks like you already got relevant testing and were able to merge? also, looks like your approach in #250 has rails-sprockets merge the broccoli-generated manifest during an asset build (similar to #181)? If so, then that's the core of the pull we were looking for.

[seanpdoyle]

@skylar I ended up backing out of using the manifest.

Didn't end up needing it.

I've merged the Addon PR and the Gem PR into their respective masters, but I haven't released yet.

I'd still love as much user-testing as possible, since I only have experience with a subset of the gem's use cases

[kayakyakr]

@seanpdoyle, there's a lot of information in this thread and I'm trying to get through it. I think I ran into an issue with adding the dist path to the asset pipeline: this doesn't work when we are skipping the asset pipeline, as in an nginx, self-hosted assets situation. I haven't dug very deeply, yet, but in production, the pipeline isn't running at all, so adding the dist directory does not work.

Will probably solve, for now, by writing a task that loops through and copies the assets from dist to deploy.

[seanpdoyle]

@kayakyakr I'm not sure of your particular use case, but as of 0.6.0, ember-cli-rails deliberately avoids integrating with the asset pipeline.

In what ways doesn't ^0.6.0 support your use case?

[kayakyakr]

Sorry, that was the older stuff. So serving stuff via Rack::File is great when you're using the rack server to serve assets. If assets are being served directly via nginx or in some other form, they will need to be copied to assets on deploy.

I wrote a deploy task to link the assets in the ember build to the public assets folder:

after "deploy:compile_assets", :ember_assets do
  on roles :web do
    execute :ln, '-sf', "#{release_path}/tmp/ember-cli/apps/home/assets/*", "#{release_path}/public/assets/"
  end
end

[seanpdoyle]

@kayakyakr I see.

That capistrano task looks good to me, although it depends on /tmp/ember-cli/apps/home pointing to your app (which it currently does, but isn't exactly part of the gem's public API).

I recommend serving the Ember assets over a CDN, since it relies on EmberCLI's public API, and isn't dependent on the underlying (private) directory structure.

[kayakyakr]

Eventually, but we're not ready to publish to a CDN, so I'll have to hack it for now.

[skylar]

@seanpdoyle I finally had a chance to checkout your latest build. The code looks great! Better yet, I was able to migrate from 0.3.x to 0.7.x without too much of a fuss. Given the nature of our app, we have to handle at least 25% of our routes in rails (eg, custom controller/actions) when bootstrapping the ember app. (The others are just pass-throughs to 1 of 2 standard ember-app renders).

What this means is that mount_ember_app seems to not be an option since we need to define many custom route handlers. (Are there provisions for this in your new system?) The workaround for this is simply adding EmberCli[:app name].build in our app controller method (eg, ApplicationController::render_ember_app). Also, I had to add a call to mount_ember_assets to the route file.

There are a couple of asset bugs to sort through, but nothing major. It seems the issues from this PR are more or less handled for me too.

That said, I was wondering, do you see any specific issues for "legacy" ember-cli-rails apps that call build on their own and simply mount the asset paths? Anything I might be missing?

[Samsinite]

@skylar you can see mount_ember_app defined here, and that it is just creating a get scope with a bunch of default options. You can really just define your own get scope however needed. And of course, if it is the last defined route, others will have precedence too. We keep mount_ember_app defined as the last route in our route file, even after this:

  # Clobbers all /api/* routes, Keep this as the second to last route in the routes file
  match '/api/*path', to: 'ember_application#api_not_found', via: :all

So our route looks something like this:

  # other routes and stuff...

  # Clobbers all /api/* routes, Keep this as the second to last route in the routes file
  match '/api/*path', to: 'ember_application#api_not_found', via: :all

  # Mount the ember app
  mount_ember_app :frontend, to: "/", controller: 'ember_application'

Our controller looks like this:

class EmberApplicationController < EmberCli::EmberController
  skip_before_action :authenticate

  def api_not_found
    render status: 404, nothing: true
  end
end

Here is an example template with extra stuff:

<%= render_ember_app ember_app do |head, body| %>
  <% head.append do %>
    <%= csrf_meta_tags %>
  <% end %>
  <% body.append do %>
    <% if Rails.application.secrets.server_status == 'development' %>
      <div id="pipeline-flag">
        <div class="development-flag">
          <p>Development</p>
        </div>
      </div>
    <% end %>
    <% if Rails.application.secrets.server_status == 'staging' %>
      <div id="pipeline-flag">
        <div class="staging-flag">
          <p>Staging</p>
        </div>
      </div>
    <% end %>
  <% end %>
<% end %>

Really, this gem is much more flexible and awesome with the latest set of updates. We also keep using a proxy, with ember serve in development for speed and developer happiness, as the build times are slow and it also handles reloading without any extra setup.