From the Phoenix 1.3 User Guide: “If we already have code that assumes jQuery is available as a global variable, we’ll either need to migrate our code (which is a must-do in the long run), or leave jQuery as a non-wrapped codebase (which is acceptable as a transition hack).” https://hexdocs.pm/phoenix/static_assets.html
What does that mean? I’ve installed material-design-lite and mdl-ext. The way I have these working is to add them as globals:
npm: {
enabled: true,
styles: {
'material-design-lite': ['dist/material.min.css'],
'mdl-ext': ['lib/mdl-ext.min.css']
},
globals: {
material: 'material-design-lite',
'mdl-ext': 'mdl-ext'
}
}
And then to import them inside app.js
import "material-design-lite/material";
import "mdl-ext";
They’re just providing some classes in the html. Simple stuff. Just confused by the docs.
See Globals; because, reasons.
In the case of jQuery the early practice was to simply attach the jquery object to window:
// Expose jQuery to the global object
window.jQuery = window.$ = jQuery;
That is what the sample globals configuration will do automatically for you inside the JS bundle that brunch creates. However current practice is to keep everything in a JavaScript module. Then the globals are no longer necessary because jQuery is accessed explicitly through the module mechanism:
const $ = require('jquery'); // CommonJS module - e.g. used inside node.js
import {$,jQuery} from 'jquery'; // ES2015 module syntax
See also ECMAScript 6 modules: the final syntax
However browsers are only now starting to support ES2015 modules on an experimental level. To get the benefit of modules in the browser it has been necessary to use “bundlers” like browserify - and brunch is a bundler.
Now import statements are also used with CSS files because CSS modules try to move beyond the CSS Block Element Modifier naming convention as a means for avoiding naming collisions. These styles are applied inside JavaScript code; but sometimes such an import is simply used to communicate to the bundler that the CSS is being used and needs to be bundled (e.g. Webpack).
It is my impression that mdl never supported CSS modules - that only started to be supported in Material Components for the web - which is why there is a warning that mdl is in limited support.
Brunch can bundle CSS files - but that is simply a matter of configuration to create a bundled app.css file. So I’m not even sure if you are even getting any benefit from the mdl globals configuration or the import statements in connection with your styles. However brunch does need to know where to find the CSS to put into the CSS bundle.
The Brunch fundamentals are covered in The Brunch.io Guide.
2 Likes
Shoot, sooooo much to learn 
I’d not come across CSS modules but the link provided by @peerreynders is most persuasive.
This also helps to put the Material Components help into context.
In phoenix there are the .eex templates which get combined as a render function inside the view (that’s my simple understanding). Can these support CSS modules? Given that we seem to be writing for the builder and not the browser.
Sorry that this forum for phx and elixir has become slightly polluted with discussion about js!
The idea is to pick one CSS library and framework and stick with it - in the hope of being isolated from all the nitty-gritty details. But a certain amount of CSS knowledge is required to apply the customizations needed to use these styles effectively anyway. Of course some people don’t like the bloat and possibly excessive conformity and rather write their own CSS.
Well, that’s a matter of perspective. “CSS modules” is a “CSS in JS” technique. EEx templates are rendered in Elixir - so I say no. That being said EEx templates can reference JavaScript files which can use “CSS modules” but that would only apply to the client-side rendered portion of the page.
I only mentioned “CSS Modules” because you are bound to come across examples where CSS is imported into JS. Brunch itself doesn’t support “CSS Modules”, it can run CSS preprocessors and bundle CSS files. “CSS modules” are big with React/Webpack (Webpack changes class names by default to [hash:base64], you have to explicitly configure [local] to retain the original names).
postcss-modules is a variation on the theme for templates that can be processed by JavaScript and something like
<h1 class="<%= className('styles', 'title') %>">The Hubble Space Telescope</h1>
is used to scope the CSS.
However “CSS in JS” isn’t without it’s critics - for example CSS in Depth author Keith Grant has some blog posts on the matter:
Most CSS libraries/frameworks follow some methodology like OOCSS, SMACSS, BEM, ITCSS, ACSS, MaintainableCSS, etc. to deliver modular CSS. So the style of modular CSS design (you use in EEx) is dictated by the CSS library/framework you choose.
@peerreynders ‘pick [something] and stick with it’ made me laugh - I’ve trundled along with angular (mongo, mongoose, less etc), then liked meteor integrated with angular2 until they went too commercial, and now elixir. Of course, back in the day, it was Rails. And countless other libraries. So pleased I don’t configure this stuff for a living 
I’ll not go down the CSS modules path with my personal phoenix app and I don’t have the need for any js libraries just now (outside the styling) so I guess the “acceptable as a transition hack” doesn’t apply to me.
NB I did experiment with Material Component but found the select component (often hard for CSS frameworks) wasn’t quite there yet. Also like polymer. But by the time these frameworks have enough help and examples for the perpetual beginner the world will have moved on.
Even “just” using jQuery can be a polarizing topic.
