I'd like to get a better understanding on how I can structure my css files. My folder structure is like so:
-app
|-src
||-components
|||-app.js
||-styles
|||-styles.scss
|-webpack.config
So I have one stylesheet that will be imported into app.js and cascade to my other components. But as I'm creating more components, my stylesheet is getting pretty long. Is it best practice to have stylesheets per component? Also, I'm using webpack to compile and extract my stylesheet into a css file to import into index.html file. If I have multiple files, I'm assuming webpack will compile all of them into one css file?
When your application scales it becomes hard to maintain a huge CSS file , not to mention class name collision , so files separation its generally a good idea.
I prefer CSS file per page , kind of up to you how to separate them.
As for webpack loaders , think of it as a pipe , the pipe sets rule that every file that ends with .css comes in and bundled, so yea , it will bundle multiple css files.
Related
I have a _common.scss file which I import to various page.scss files:
page.scss:
#import "common";
#page {
...
}
_common.scss:
#import "partials/all";
#import "components/all";
...
But the problem is, since all my pages import _common.scss, the way I have things structured, if I make any changes inside _common.scss (or any of the files it imports), sass has to rebuild all the page css files. But if I just make _common.scss its own file and call it with a <link> tag (<link href="common.css">), then the page.scss file has errors, because it is trying to use variables and mixins defined in _common.scss and its imports.
Is it possible to structure my project so that the page.scss files can use all the mixins and variables in _common, but so that sass doesn't have to rebuild each page.css file each time I make a change to the common file? i.e. - make it so that sass only builds the common file when a change is made in common, and only builds the page file when a change is made in page?
I would say it is not possible, since the aim is to have one css for each page at the end. This said it HAS to be rebuild if something is changed in common.
please excuse my inexperience with, and lack of understanding of, Sass.
Basically I was assigned to do some edits on a site which has a main css page and a few scss subpages, all organized through an ftp directory.
I'm just confused how the index knows where to pull the scss pages in the ftp directory? I've looked through the code for the index page, as well as the linked css and js pages, and can't find any part that references the scss pages. Yet they still load within the original css? Am I missing something?
Thanks for the clarification.
SCSS is a preprocessor language. That means it will be converted to CSS. The SCSS files do not get loaded by the website. Instead you will have to make your changes to the SCSS files and then convert them to CSS. It is likely that there is a system in place which takes care of that for you. Take a look around and find out whether there is a gulpfile or a gruntfile hanging out somewhere.
The main.scss file gets compiled to the main.css file. The output produced by the sass compiler replaces the main.css file. There is no link. You need to compile your main.scss file using sass.
Apart from that, you use 'CSS file' rather than 'CSS page' as CSS is an acronym for cascading style sheet which is definitely not page in itself.
Web browsers don't know what a SCSS or SASS file is. They only load CSS.
Your site could have a build tool (grunt, gulp, rake etc) to compile your .scss source files into .css files, which is then published to your web site.
Sometimes your application server will know how to do the translation on the fly and you can just edit the .scss file.
A lot of the time many .scss files will be combined into one .css file so you are often editing a different file to what you would expect when you look at what .css is loaded the browser.
in my current meteor app I have split the less declarations in one file per Controller (iron-router). I have a common file - where I have defined some mixins - which is imported in each less file. My problem is that the classes are imported multiple times in each route.
The file structure is:
mixins.import.less (new names, reference http://docs.meteor.com/#less)
.grid-container {
// something
}
postList.less
#import (once) url('/client/views/mixins.import.less');
postDetail.less
#import (once) url('/client/views/mixins.import.less');
Then in the Chrome inspector I found duplicated everything I have written in mixins.import.less. Is it possible to avoid this double import?
Assuming you want the mixin code at least once in your compiled css (perhaps not, some just want them as mixins, not classes in the css code), then make sure you set it to bring in the "mixins.import.less" file all by itself. Then for all your dependent files using it, do this:
"postList.less", "postDetail.less", etc.
#import (reference) url('/client/views/mixins.import.less');
The (reference) option has been available since LESS 1.5, and will only bring in the code for reference purposes to be used in the LESS file, but will not itself output any css.
Meteor bundles css and js/html resources all together as a single css and a single js file in production.
In development, they are individually served, but still at the same time, during initial page load (first ever request to server)
For less files, a css file is created for each (during development). Since you are importing, what Meteor basically does is create each corresponding css file that each contain the import individually.
And when they are served to the client all together (take a look at the head section of the generated html), you end up with that many copies of the imported style declarations.
Therefore, due to this bundling behaviour of Meteor, you can just keep one copy of your less mixins in a less file, and not import at all, since they are going to be served to the client in CSS form anyway.
Also, it is possible to trick Meteor into bypassing as described in the unofficial meteor faq:
... you can change the extension of the less files to be imported from .less to .lessimport and then change your #import file.less to #import file.lessimport. This will prevent the less compiler from automatically trying to compile all your import files independently, yet still let you use them ...
I'm wondering if its okay to import all of bootstrap.less into my own .less file and then overriding anything I wish to change within that one file. My own .less file, style.less, outputs everything into a single style sheet, and I'm NOT including the compiled bootstrap.css file, only the JS files.
bootstrap // folder with all bootstrap less files.
style.less // imports bootstrap folder, and outputs style.css in root directory
Are there any drawbacks to doing it like this, or should I also be including the compiled bootstrap.css file?
Yes, do, you immediately gain access to all the mix-ins and variables. I'd say this is the most powerful way to use bootstrap.
As you're suggesting just import bootstrap.less at the head of your less file. I import any other mixin libraries, like lesshat, after that.
The problem is that you end up with one monolithic CSS file which is a nightmare to debug, but less.js 1.50 introduces source maps which is invaluable when using this methodology: http://robdodson.me/blog/2012/12/28/debug-less-with-chrome-developer-tools/
A faff to set up but saves a lot of head scratching.
I am planning on dividing up my LESS CSS into multiple files to modularize my CSS and make it easier to manage and maintain. Ultimately I will be using #import to import all of my modular CSS files into one file that will get enqueued in WordPress.
Is #import a bad idea for performance?
Yes, using multiple imports will incurr equivalent number of file requests the browser has to make.
As long as you compile the LESS source into a CSS file and include that CSS file as the stylesheet for your site, performance will not be an issue.
For example when you make a Wordpress theme you can make a folder for your CSS and then compile it using for example simpLESS (if you are on Windows)
Sample template directory structure:
-themes/
-your-theme/
-less/
-main.less
-import.less
-etc.
-style.css <- this is the target file you would compile into
-index.php
-etc.
You can setup the target file to compile into easily. Also, simpLESS will keep the first top comment in the resulting file so that you can put your theme information in it.