Where the F is JST coming from?!?
If you’ve built a Rails + Backbone app you know that a common way to use templates is by writing files with the
.jst.ejs file extension. Additionally, you may take for granted the fact that these templates are precompiled
_.template style for you. As you know they are made available in the JST namespace via properties with the same name as the file (including directory).
I had to stop and think on it for a bit. Where do these come from. Are they added to application.js? No. Are they injected into the HTML as template script tags? No! The secret is in the asset pipeline. The sprockets gem has a JST Processor which slurps up the .jst files and transpiles them into .js files! In development you’re assets directory gets fatter by the number of directories in your app/assets/templates. In production these all get concatenated into application-fingerprint.js. Each generated JS file contains an IIFE which memoizes the definition of the JST namespace, then appends to it the result of running the ejs compilation step which returns the compiled template function.
First checkout the JST Processor
Then read every line (100) of the ejs gem
This gist is pretty good at explaining the resulting IIFE.
Going even deeper down the rabbit hole!
How does the asset pipeline even know what to do with the .ejs file? Where is that section of the pipeline added?
It turns out that the sprockets gem is yet another step ahead of us. Checkout the EJS template and the EJS Processor. Sprockets will look for the EJS ruby constant to be defined, and if it is will call EJS.compile when evaluated.
So now you know! When Sprockets loads and starts processing a file with the extension jst.ejs it will call the EJS processor, which will call the EJS template which will call into the EJS gem to get back the compiled result of the ejs template. Then the result is processed by the JST Processor which wraps the compiled template in an IIFE and sets up the JST namespace.