Splitting CSS files
-
My company has already some different reports that share common CSS. As the reports grow, also grow the CSS we've been mantaining, so in order to make it something more manageable, I wanted to split it into different CSS files and mix-and-match according to my needs to each report. The idea is something like:
/shared /css base.css system-font.css ...
And whatever else we needed. With that structure, I wanted to then import, for example,
system-font.css
intobase.css
. That's where my problem begins, as I can't do it using CSS's@import
statement, and trying to use JSReport's{{asset}}
doesn't work either - possible assets inside the "imported" CSS file are not correctly parsed and included in the final file. How should I proceed to do this? Is it even something possible to be done?In this playground it's possibile to see what I've tried to explain above.
-
I see, so what you want is to extract an asset that is inside another asset.
This isn't supported, but you can use components extension instead.
https://jsreport.net/learn/componentsSo in your case you create a component instead of the asset
image.css
and then the helpers call insideurl("{{asset '/assets...
will work properly.
-
Thanks for the help @jan_blaha. I'd read about components already, but it was my understanding they were meant to be used to split the template i.e. split parts of my report's handlebars template. I'll give it a try then.
-
Another thing I tried and haven't been successful in doing is using CSS's native
@import
to load different CSS files into one. Is that something possible, with a file URL inside the directive, instead of an{{asset}}
?
-
Interestingly enough, using the old
{#asset}
directive to inject the assets works perfectly - I can split everything into different files and mix-and-match as I wanted. Should that be considered a regression bug, maybe?
-
Another thing I tried and haven't been successful in doing is using CSS's native @import to load different CSS files into one. Is that something possible, with a file URL inside the directive, instead of an {{asset}}?
The
@import
would require us to expose your assets over HTTP and serve it to the chrome and that would have some security implications so we rather decided to not support this for now. Also, the@import
for asset wouldn't work in other recipes that don't use a browser. We may still reconsider this just for thechrome-pdf
, but it isn't a big priority now. It's just nice to have for problem which can be easily solved otherwise. Although I understand for developers starting with jsreport the@import
is the first idea, so let's see...Interestingly enough, using the old {#asset} directive to inject the assets works perfectly - I can split everything into different files and mix-and-match as I wanted. Should that be considered a regression bug, maybe?
Yes, the old syntax is applied recursive and runs before the templating engine evaluations so it supports this.
It isn't regression that the new way of using the helper callasset
isn't recursive. It's by design and also documented. This decision was mostly done because of the performance - re-evaluating handlebars on assets takes time. The assets are static and in case you need to nest them and use the handlebars inside, you should look at the components.