7

I have a project with 6 views (html). Each of those views has a corresponding view model (.js) and a style sheet just for that view (.css)

The aurelia-cli does a wonderful job of recursing through my file free and bundling all the .js and .css files into a couple of files so they can be referenced while reducing page load times and size. So if I have a welcome folder with a welcome.html, welcome.js and welcome.css, I can load the CSS for welcome.html with the following <require from="./welcome.css"></require> and the CSS will be injected into the <head></head> tags on page load.

The problem with that is when I navigate to the next view the CSS rules from welcome.html / welcome.css are still within the <head> tag of the webpage thus still being enforced. After visiting all 6 views in my application I now have 6 <style> tags within the <head> tag with all of the rules from all six pages being enforced on every page I go to with no unloading taking place until the page is refreshed. Needless to say after visiting a couple pages the entire site becomes jumbled garbage.

So my questions are

  1. Why is this a feature
  2. Am I missing a best practice here?
  3. Is there a way now to load the css for a page when visited, unload it when navigated away, and load the new pages css in it's place?

If I had a 10 page app with a global stylesheet, bootstrap, animate css, and font awesome, at the end of the day I have 14 conflicting styles injected permanently into the html the rest of the app is injected into.

Any suggestions?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Scott Clark
  • 608
  • 6
  • 21

1 Answers1

3

After facing similar situations, experimenting for long hours, I came to a simple conclusion: I'm not fond of this 'injecting CSS files everywhere' approach. Allow me a little rant about it, please. :)

What is the benefit of it?

  • We've already created a combined, global stylesheet with usual things (bootstrap, font-awesome, etc..). Presumably, it's in the head section of index.html. Of course, because we'd like to have a nice splash screen before the app loads itself. Even in the official skeleton-navigation app
  • Another reason to avoid <require> is its async nature, which gives us little (or no) control over the CSS load order. It's perfect for JS modules/custom elements but not for multiple CSS files.
  • And at last, there are these other <require> tags placed in each view, just to make our already 'simple' situation even more 'straightforward'.

So, wouldn't be easier to pack the rest of the app stylesheets into this already existing global stylesheet, in an explicit order?

My proposal

Aurelia-cli has a great feature, called generators. You can extend its functionality, as you'd like. With this in mind, you can create new tasks for custom CSS pre/after-processing and insert them into the build process.

  • You have full control over the process.
  • 1 minified file will be created. It'll contain everything in the expected CSS load order.
  • A small application's CSS file size is like ~10-30KB, right? It won't hurt. :)

I've created a small project couple of days ago, which addresses this issue as well: aurelia-custom-skeleton. Working demo here.

  1. During the build process, it creates a base.css from global deps, and an app.css from custom CSS files. This is for debug purposes.
  2. These two files are combined into styles.min.css, which is deployed and referenced in index.html.
  3. If you need to create a truly self-executable app, without external files, you still have the ability to embed this 1 combined stylesheet.
Community
  • 1
  • 1
Marton Sagi
  • 1,247
  • 1
  • 8
  • 10
  • I guess it's just confusing me why aurelia does not unload the CSS the same way it brings it in. I do not find sound logic in bringing using a css for one page on multiple pages. What benefit does this provide? I'll take a look at your solution but I wonder if this is work bringing up as an issue on github. If it provides no benefit, it should be fixed. – Scott Clark Sep 07 '16 at 18:12
  • Couldn't you just use sass's @import feature to import the scss files in your desired order? Then, just require the top level scss file from the app itself. – pQuestions123 Sep 14 '16 at 16:00
  • Which really brings up another issue of not having access to variables set in specific variables files (i.e. colors etc.). My go to solution is just to import all scss into one master scss file (which imports colors.scss at the top). Then you have access to all colors in all files. All you need to do is transpile that one master file. – pQuestions123 Sep 14 '16 at 16:02