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

images and other assets #30

Closed
samselikoff opened this Issue Dec 20, 2014 · 71 comments

Comments

Projects
None yet
@samselikoff
Contributor

samselikoff commented Dec 20, 2014

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

This comment has been minimized.

Collaborator

rwz commented Dec 20, 2014

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

@samselikoff

This comment has been minimized.

Contributor

samselikoff commented Dec 20, 2014

hmmmmmmmmmmmmmm

@samselikoff

This comment has been minimized.

Contributor

samselikoff commented Dec 20, 2014

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

This comment has been minimized.

Collaborator

rwz commented Dec 20, 2014

`¯_(ツ)_/¯

Any suggestions?

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

@rondale-sc

This comment has been minimized.

Collaborator

rondale-sc commented Dec 20, 2014

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

This comment has been minimized.

Collaborator

rondale-sc commented Dec 20, 2014

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

This comment has been minimized.

Contributor

samselikoff commented Dec 20, 2014

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

This comment has been minimized.

Collaborator

rondale-sc commented Dec 21, 2014

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

This comment has been minimized.

Collaborator

rondale-sc commented Dec 21, 2014

@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

This comment has been minimized.

Contributor

rwjblue commented Dec 21, 2014

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

This comment has been minimized.

Collaborator

rwz commented Dec 21, 2014

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

@rwjblue

This comment has been minimized.

Contributor

rwjblue commented Dec 21, 2014

True, but things would work ;)

@rwjblue

This comment has been minimized.

Contributor

rwjblue commented Dec 21, 2014

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

This comment has been minimized.

Collaborator

rwz commented Dec 21, 2014

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

This comment has been minimized.

Contributor

rwjblue commented Dec 21, 2014

@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

This comment has been minimized.

Contributor

rwjblue commented Dec 21, 2014

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

This comment has been minimized.

Collaborator

rwz commented Dec 21, 2014

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

@rwjblue

This comment has been minimized.

Contributor

rwjblue commented Dec 21, 2014

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

This comment has been minimized.

chrisdevor commented Jan 9, 2015

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

This comment has been minimized.

Collaborator

rondale-sc commented Jan 9, 2015

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

@chrisdevor

This comment has been minimized.

chrisdevor commented Jan 9, 2015

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

This comment has been minimized.

chrisdevor commented Jan 10, 2015

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

This comment has been minimized.

TeknoFiend commented Feb 16, 2015

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

@ljuti

This comment has been minimized.

ljuti commented Feb 16, 2015

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.

@oliver----

This comment has been minimized.

oliver---- commented Feb 20, 2015

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

This comment has been minimized.

rainkinz commented Feb 24, 2015

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.

@oliver----

This comment has been minimized.

oliver---- commented Feb 24, 2015

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

@gniquil

This comment has been minimized.

gniquil commented Mar 11, 2015

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?

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 8, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30
@Samsinite

This comment has been minimized.

Samsinite commented Nov 8, 2015

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

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 9, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 9, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30
@seanpdoyle

This comment has been minimized.

Collaborator

seanpdoyle commented Nov 9, 2015

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

Any success with #30 (comment)?

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit that referenced this issue Nov 10, 2015

Defer to EmberCLI build pipeline
Closes [#30].

Depends on [rondale-sc/ember-cli-rails-addon#17][#17].

* Symlink `dist/` directly to Asset Pipeline
* Deletes `EmberCli::AssetResolver`
* Improve `bin/setup`, resolve errors.

[#30]: #30
[#17]: rondale-sc/ember-cli-rails-addon#17

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30

seanpdoyle added a commit that referenced this issue Nov 10, 2015

Defer to EmberCLI build pipeline
Closes [#30].

Depends on [rondale-sc/ember-cli-rails-addon#17][#17].

* Symlink `dist/` directly to Asset Pipeline
* Deletes `EmberCli::AssetResolver`
* Improve `bin/setup`, resolve errors.

[#30]: #30
[#17]: rondale-sc/ember-cli-rails-addon#17

seanpdoyle added a commit to rondale-sc/ember-cli-rails-addon that referenced this issue Nov 10, 2015

Prepare URLs for Sprockets Asset Pipeline
Initial steps toward closing [thoughtbot/ember-cli-rails#30][#30].

* Prepend Sprockets path to EmberCLI assets.
* Default fingerprinting to no generate `MD5` hash when building in
  `development`.

[#30]: thoughtbot/ember-cli-rails#30
@skylar

This comment has been minimized.

skylar commented Nov 10, 2015

@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

This comment has been minimized.

Collaborator

seanpdoyle commented Nov 10, 2015

@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

This was referenced Nov 12, 2015

@kayakyakr

This comment has been minimized.

kayakyakr commented Dec 28, 2015

@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

This comment has been minimized.

Collaborator

seanpdoyle commented Dec 28, 2015

@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

This comment has been minimized.

kayakyakr commented Dec 28, 2015

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

This comment has been minimized.

Collaborator

seanpdoyle commented Dec 28, 2015

@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

This comment has been minimized.

kayakyakr commented Dec 28, 2015

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

@skylar

This comment has been minimized.

skylar commented Feb 19, 2016

@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

This comment has been minimized.

Samsinite commented Feb 22, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment