Newby Question: how to link an external CSS file to an app in OnDemand

I am trying to link an external css file to my OnDemand app that I am developing. I am not sure what the best practice is as to where to store this file and how to link it to the view.html file.
I am brand new to the OOD community, so apologies if this is a dumb question. I work on the Tufts OOD website, and am working on making apps like quotareport display nicely on a web page. It works now but it is spaghetti code that was done as a proof of concept. Trying to find out how to do things legititimately, such as having an external CSS file instead of putting all the styling rules in a <style> tag.

Where I am at:
I have the css file stored in quotareport/styles, a directory I made. But when I link that file in the views.html file for quotareport, I get the following error:
Refused to apply style from 'https://ondemand.cluster.tufts.edu/pun/dev/quotareport/styles/quotareport_styles.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

1 Like

So you have a separate css file that is included with your app and you want to embed it?

Here is an example in Ruby:

and corresponding files that are referenced: https://github.com/OSC/ood-example-ps/tree/c912ca87cc563be55cbf5d1bc896fd3bd7718f9d/public

Whether its Ruby, Python, or NodeJS the concepts are the same:

NGINX will serve the files directly that are in the public directory in your app. The URL of these assets will be after the base uri of your app, so if your app’s base uri is /pun/dev/quotareport and you place your css under public/styles/quotareport_styles.css then /pun/dev/quotareport/styles/quotareport_styles.css should be retrieved.

Now at this point its just important that you prefix “/styles/quotareport_styles.css” with the base uri dynamically (i.e. in the above code I use a url helper method which does this) so that when you deploy the app to production the link does not break.

Does that help?

1 Like

Note that if you take this approach, I recommend choosing a cache busting strategy. Otherwise you will face the annoyance of modifying the css file but not seeing the change because your browser will have cached an older copy.

Strategies include:

  1. appending a query param with a timestamp to the end of the URL in the HTML
  2. renaming the file so that there is a timestamp or some other value at the end of the file
  3. using some “asset compilation” tool that will auto-generate these time stamps (webpack, sprockets, etc.)
  4. you could write Node.js or Python or Ruby code to serve the CSS file instead of putting it in public and having NGINX serve it; this will be slower, but then you could have the route change dynamically or optionally specify the caching response headers you want to use

Actually it seems like we could probably do some extra work to configure NGINX so that it will auto-invalidate cache based on modified timestamp of files in the public directory. I imagine that could be helpful for developing apps. I’ll open an issue to consider that.

1 Like

Thank you for the help! It is greatly appreciated. I will see if that works soon, but it all makes sense :slight_smile: