I am using the jstree (https://www.jstree.com/) jQuery library. Works fine in development but in production all the standard background CSS breaks. The css calls the background icons from /app-assets/32px.png etc. These files are in my /app/assets/images and even added them to my pre-compile but none of them load (throw 404 errors).
I suspect the issue is that I deploy to production Rails is pre-compiling the images and when the jstree css calls url("32px.png") the server calls /app-assets/32px.png which will always fail because the server is expecting the /app-assets/32px-xxxxxxxxxxxxxxxx.png precompiled asset pipeline url.
I can manually dump the icon files in the public folder and hack the css but the JS seem to still trigger code for the old path. Can I get JS tree to reference the Rails asset pipeline urls?
The ended up being the CSS which calls for the background to be url("32px.png") and in the Rails world that is relative to the pre-compiled CSS that is under /assets/...
I placed my jstree images in the static /public folder and then changed the CSS to url("/32px.png") so that jstree loads them absolute from root.
There is an option to use image-url("32px.png") but the jstree JS fails when it tried to load the images as it tries to still load the relative path and I saw some double loading of the image files etc. I gave up on that and opted for the first solution.
Hope this helps someone down the road.
Related
I use to host my CSS files in the rails asset pipeline and JS on webpacker. I recently realize my webpage has been loading slower and slower.
I ran Chrome lighthouse on my site and found that my CSS and JS assets are "render-blocking resources" and causing my page to load slower.
I've already tried moving all of my CSS and JS over to webpacker (semantic-ui css is still being imported by the rails asset pipeline, had lots of problems trying to make this work but couldnt still)
I notice on Chrome lighthouse that my load time improved marginally, I guess its from the minification of CSS and JS by webpacker but it's no where near the improvements I was looking for.
So my question here is, what is the most efficient method to serve CSS and JS files for rails app?
My app is hosted on Heroku's Hobby Tier.. could this be a factor as well?
Both approaches should allow you to achieve similar results. I don't know rails asset pipeline, but if it's used similarly to webpack it just changes your files on the build time & it's up to you how much code the user gets to download.
First of all, you can check the output size - in webpack, you can check the build standard output, or directly check the files it creates.
One trap you could be failing into with webpack is to have it set up wrongly. It could anything, from not minimizing code when for production build to having loades set up in a way that makes your images included directly inside js as data URL.
One advantage of using webpack, is that allows you to set up more complicated loading logic - for example lazy loading. Here something more about lazy load:
https://dev.to/marcinwosinek/lazy-load-library-in-application-build-with-webpack-5757
For an application built on top of Rails (3.1.8) with ExtJS 4.1, we have the following files layout:
app/
assets/
javascript/
application.coffee
WID/
Lots of coffeescript files and folders.
public/
extjs/
ext-all-debug-w-comments.js and the whole ExtJS framework.
Our application heavily relies on the Ext loader (Ext.Require) to dynamically load files based on users rights / allowed modules. We would like to keep this functionality as much as possible, so only the required files are requested from the server. Bandwidth isn't really an issue, as the application is intranet-based (On a LAN).
In development environment, everything runs smooth. In production environment however, we are having problems. It looks like either the "rake assets:precompile" task is concatenating all files into an application.js file, and then when accessing our application the Ext loader complains that it can't find individual files (Because assets/WID/.../file.js isn't being served by the rails server).
So right now, i'm not sure what would be the best move to take... Is there anyone able to help us with a successful Rails + ExtJS production setup taking the best from the assets pipeline?
Thank you,
Pierre.
I think you should move your javascripts (and generally all the assets) from your public into vendor/assets/javascripts when you are in development environment. This way the asset-pipeline gets in charge.
EDIT: You may consider reverting your manifest file to application.js, not application.coffee. Generally it is a bad idea to rename these special files : application.css and application.js .In case you have some coffescript to add , just create a new file and place it in an asset directory.
My site has problems with finding javascripts and some of the images. It cannot display the images that is located within folders in the assets/images/ and none of the js and jquery.
The css works fine. But the weird thing is that when I moved the images down one folder to the assets folder, they still didn't work. Been trying to find something in assets pipeline guide:
http://guides.rubyonrails.org/asset_pipeline.html
But without a result. Could it be related to some precompiling? I tried some precompliling, but no changes.
I'm open for all suggestions! Thank you.
Edit: After som more research I found that it has generated most of the files in a folder in public/assets, and it grabs all files from there. I don't know why it generates them to that folder nor how to direct it to grab them from app/assets/javascripts.
See http://guides.rubyonrails.org/asset_pipeline.html#upgrading-from-old-versions-of-rails to find out how to change the asset path.
I'm just getting into the Asset Pipeline; I'm using SASS/SCSS, but I'm not understanding why I should be using the Asset Helpers.
For example, if I have some CSS/SCSS without using an Asset Helper:
background-image: url('rails.png');
This will work fine because both my .SCSS file and image are in and accessible through the assets directory.
What's the point of doing this?:
background-image: asset-url("rails.png", image);
I understand it will add "/assets/" to the url, but why should I be using the Asset Helpers if the standard CSS way will work?
I think I'm missing something. Does it have something to do with deploying to production?
Using the helpers gives you access to the finger printed URLs in production. From the Asset Pipeline guide:
In the production environment Rails uses the fingerprinting scheme outlined above. By default it is assumed that assets have been precompiled and will be served as static assets by your web server.
During the precompilation phase an MD5 is generated from the contents of the compiled files, and inserted into the filenames as they are written to disc. These fingerprinted names are used by the Rails helpers in place of the manifest name.
So in production, the paths have an MD5 appended and you have things like this:
/assets/pancakes-af27b6a414e6da00003503148be9b409.png
With the checksums in place, Rails can tell browsers to cache these files forever. Then, if you do a new release that changes one of your assets, the checksum changes and that changes the whole path; the new path makes the browser think it is a whole new file so it will fetch it again. Without the checksums you can easily get old files stuck in browser caches and that sort of thing isn't exactly a happy fun time.
After I deployed my upgraded Rails 2.3.x -> 3.1 (rc4) app to our test environment this afternoon, all of our stylesheets and JavaScript files were returning 404 errors. We had added the rake assets:precompile task to our post-deploy script and it took a while to determine why the assets folder didn't have the pre-compiled files we expected.
In the end, the files weren't being compiled because apparently only application.css and application.js (+ non JS/CSS files) are processed by default.
We needed to change the following configuration value as follows:
config.assets.precompile += %w( *.js *.css )
Question: why isn't this the default?
I would have expected that anything that wasn't necessary to process as a manifest file would just get copied into public/assets. Much of what I've read on the asset pipeline is essentially "stick your assets in app/assets, configure the manifest files, and it should just work". Since the assets:precompile task didn't spit out any information about what it was doing, it took a while to determine that it just wasn't looking at the files we thought it would.
Is there any reason why this would not be a good value for the precompile configuration?
Thanks!
The idea is to have all your JavaScript and CSS always loaded in one shot, rather than loading bits and pieces as you move along. That way you always have the 'world' loaded and ready to work with, rather than having to include a whole bunch of individual files here and there.
It's a bit of a larger 'up front' load, but then the browser should keep loading all the javascript from cache. So the perceived speed of the site should speed up due to having everything cached and ready to go after the first request.
This was a controversial decision to include for Rails, but so is including CoffeeScript by default. Rails has always been an opinionated framework that way.
the new sprockets-based pipeline compiles all the files in /asssets/stylesheets and /assets/javascripts get compiled into application.css and application.js, respectively, by default.
In your views, you only need to link the application files, sprockets handles the rest.
Update:
Well, you don't have to make it all into just one file... You could have an shared.js, secure.js and public.js and have them each include the parts they need...
Think of them not as javascript files, but manifest files that establish groups of javascript files which you can then include as a group with a single javascript_include_tag. While the default is to include everything in the folder into a single file, you can be always pick and choose what to include, and what not.
The 'precompile' task simply runs those manifest files and compiles the multiple files into one, while pre-processing and sass or coffee script it runs across.