Where we left off
In part 1, we examined some of the benefits of moving AngularJS templates over to the Rails Asset Pipeline. In today’s post, we’ll get a closer look at some of the implications and considerations that come with using the Asset Pipeline to serve HTML templates.
Asset Pipeline Considerations
It may be true that your AngularJS templates are “using” the Asset Pipeline, but by using the normal file name you lose the ability to leverage far-future cache expiration. In order to correctly refer to the fingerprinted version of an asset, it is necessary to use two Rails helpers.
templateUrl: “<%= asset_path(‘index.html’) %>”
Handling asset dependencies brings us back to the the second Rails helper, depend_on_asset. The depend_on_asset helper allows you to make an implicit asset dependency explicit and avoid some strange behaviors that can arise when deploying implied dependencies to production.
By using depend_on_asset, you let Rails know that it will need to recompile an asset whenever the dependency is updated. Typically depend_on_asset is included at the top of the dependent file or near the context of where the dependency is formed. So a final form of our updated templateUrl might look like so:
//= depend_on_asset ‘index.html’<br />
templateUrl: “<%= asset_path(‘index.html’) %>”<br />
This may not be the most offensive code you’ve seen this week, but the addition of this dependency has far reaching consequences that are often overlooked and can require additional infrastructure changes to reconcile.
Further on down the rabbit hole
As I’ve said before, depending on your application, you might not care about browser caching. This might not matter if your application isn’t under active development. Similarly, you’re also less affected if your application is a single-use type application that’s not subject to repeated visits (browser caching isn’t of incredible utility in this case anyway).
Dr. ng-love or: How I learned to stop worrying and love (or at least tolerate) more HTTP requests
A final note on the increased number of HTTP requests: Client-side templates may lead to more HTTP requests. You can combat this by grouping templates into logical modules to reduce the number of requests required. That, however, is an article for another day.
While using the Asset Pipeline to compile client-side templates may require a deeper understanding of the technology stack, it comes with some pretty radical benefits. Though the exact implementation will vary depending on the need of the application, using the Asset Pipeline for client-side templates is a win in almost every single case. If I’ve missed something, you disagree, you want a better example, or you have a question, drop me a note in the comments. I’d love to hear about it.
Treat client-side templates like assets
- Helps maintain separation of concerns: Don’t cross the streams
- No controller action required
- Reduces dynamic code/data injection
Can be served directly by web server
- Better gzip compression than web server’s on-the-fly compression
- Fingerprinted filenames for far-future cache expiration
- May need X-Sendfile and/or additional web server config
Use Rails’ asset_url and depend_on_asset helpers to reference fingerprinted versions of templates
- Make sure web server configured to include correct Expires response headers
- Separate dynamic code from static code
- Separate static vendor assets from “static” development code
- Create lookup services for referencing dynamic values like asset URLs
Group templates where logical to reduce number of HTTP requests