Any soild reason I should prefer the sass partials over normal sass files (w/o leading underscore in the filename)?
I am not a full-time frontend developer and for now I use sass for simple organizing of my css - split styles into different files(modules/components), variables, functions, in-place calculations, mixins - I think that's all I do.
In general I create a single main sass files that combines all the files together like that:
// main.scss
#import 'vars'
#import 'funcs'
#import 'layout'
#import 'component/modal'
// etc.
And recently I noticed there is such thing as partials.
From the documentation I understand partials are independent files that are not exists on their own and are always a part of some other bigger modules.
By this logic it looks like vars.scss, funcs.scss are good candidates to be partials.
And what I can't understand is why _vars.scss is better than vars.scss.
The both variants will work well from the point of view of code splitting.
Possible reason is Compilation - the docs page says partials will not be compiled into separate css file. I can't agree that's a feature since it's fully under my control and depends only on how I configure the building tools I use. And anyway such sass internal things like variables/functions/mixins will never be translated directly to css - they only exist in the source code.
So I would like to understand maybe it's just a convention for visual separation internal files from others? You know there is a similar old practice of separation private/public members/variables in programming. Or maybe I just miss something?
Please advise what I can do with partials what I cannot do with normal files, are there any advantages of first ones?
Related
I have been using LESS for years and am only just trying out SASS. I am having trouble with a very basic thing so I hope someone can help me out.
What I want to achieve is:
a file theme.scss (which is compiled into theme.css) contains separate components (for header, navigation, font etc.)
define variables for things like brand colours to be re-used in the components
I have got it to work with #import, but because that is (going to be) deprecated I want to use #use instead. According to https://sass-lang.com/documentation/at-rules/use that should be possible.
My file setup is like this:
|- style
|- _definitions.scss
|- theme.scss
|- components
|- component.scss
Then I have this in the files:
// theme.scss
#use 'definitions';
#use 'components/component.scss';
// _definitions.scss
$base-color: blue;
// components/component.scss
body {
background: $base-color;
}
But this doesn't work: my compiler (I'm using Prepros) just says it can't find the variable $base-color. :( Note: if I replace #use by #import it works just fine.
Help?
#import will never be depricated. Sass' devs are a sleepy bunch of ****. #use is only supported by Dart-Sass yet, I assume you are using Node-Sass, which most are. Therefor you need to use #import, which makes in most use cases no difference.
You can find the info right under the heading, its the first line, virtually everbody skips.
I am looking to prefix/namespace all of clarity style rules for inclusion into our current project we are rolling clarity components / styles into. I was wondering what the best & established way to do this is. Should I be looking into PostCss plugins to namespace all of the clarity selectors? Any ideas/examples would be helpful. Presently there are some global collisions (like .btn) between clarity and our current codebase. Thank you.
Hi I am trying to organise my sass files into separate chunks on a project using GULP. However when I import my mixins and variables in separate files:
File:variables.scss
//first import variables that might be used throughout all the other files
#import "common/_variables.scss";
File:mixins.scss
Mixins
#import "common/_mixins.scss";
Then try to access those mixins from other files for example
File:buttons.scss
#import "common/_buttons.scss";
I get the following errors when running gulp sass:
throw er; // Unhandled 'error' event
no mixin named 'foo'
or
undefined variable 'foo'
In spite of the mixins/variable being defined in the variable.scss and mixins.scss files. So gulp interrupts the task half way though and the stylesheet is not created.
Is there a rule in SASS that means the variables and mixins must all be imported in the same files using them? If this is the case, it is a problem as I have a lot of files I would like to keep separate and not have to keep importing both mixins and variables inside them.
The short answer is you dont have to import them into everyfile that might include them. However there does need to be a relationship somewhere, and how you do this depends on whether or not you are looking to build one single final CSS file - or a series of individual files.
If you want the former, you could consider having a master import file that does little more than import all the appropriate *.scss files, and have this be the main SASS file your gulp build script looks to compile.
You'll need to take care to import files in the correct order - so no importing a file that uses a mixin before the file that defines the mixin has been imported it's self.
So for example - personally I work with a main.scss file that is structured as
#import "common/_variables.scss";
#import "common/_mixins.scss";
// Now import the files that might use these vars/mixins
#import "common/_buttons.scss";
which is built via gulp to create css/main.css.
Should you want a series of CSS files - i.e. buttons.css, type.css, layout.css etc - then you would need to have the appropriate variables and mixin #import declarations in each file that calls them
I found the best solution for me with pre-concating SASS files with GULP.
Like in this example for STYLUS
gulp.src(config.projects.css.source)
.pipe(sourcemaps.init())
.pipe(mktimecss(__dirname+'/web'))
.pipe(concat('styles'))
.pipe(stylus({
'include css': true,
use: [nib()],
// compress: true,
linenos: false
}))
...... and so on .......
It is most definitely possible to have your mixins and variables in different files. In fact, I'd recommend any mixins/variables that you find yourself reusing, you should take a more global approach with them instead of importing them into individual files.
One of the best ways I've seen for organizing a directory of Sass files is called The 7-1 Pattern and makes the entire structure of styling so much easier to understand and build upon.
The most applicable piece of this organizational strategy to your question would be creating a main.scss file that imports every one of the files you plan on using. Make sure you're careful about the order that you import, though. You can't import a file that uses mixins or variables from a file imported after it.
I've had a look into CSS setups for a couple of projects that other people developed and I can understand most of what's going on.
The programmers have, however, created some files whose names start with the underscore (for example: _variables.scss). I have seen files named like this in both of the projects.
I can't figure out what this convention represents. Is there a special reason why the people are naming the files this way?
The only reason I can find to use underscore before the name of the partial is what's described in the Sass docs here:
The underscore lets Sass know that the file is only a partial file and that it should not be generated into a CSS file.
Any SASS files not beginning with an underscore will be rendered on their own, which will fail if they are using variables or mixins defined elsewhere.
In the end I have concluded that the underscore is just used to clarify that it is a partial file. We can also use a partial file without using an underscore as prefix.
Sometimes that naming convention is used for templates or template part files, you could find this being used in MVC frameworks.
In other places this might mean that this variable or file is private and can only be accessed by the server or the running program. It all depends on the language you're programming really, but this is simply a naming convention.
It's just a naming convention. When you want to define a name for an interface you define it with (_interface). This is just for compatibility issues, In some cases a program may include classes and interfaces And in order to distinguish between the two, you use _ for interfaces.
This is just one example as you can use it in the BLL layer when working with databases and so on.
It is an emphasis for other developer to notice the variables and objects.
I'm going to be using NSNotifications in my app to decouple the code.
I want the compiler to help me when using strings as the names of the notifications, ie, if I mistype one, I want the compiler to tell me.
Using normal strings for this won't work, because the compiler won't know that if I typed "myNotificaion" that I really meant "myNotification".
One way to do this would be to use #defines, or const NSString variables, but that would mean they would have to be declared in a file, either the class they're originating from, or a globally included file.
The problem with having them declared in the class they originate from is that it will need to be included wherever the notifications are listened for, therefore creating a coupling that I don't want.
The problem with a global file is that it could possibly become long and messy and will contain lots of unrelated things.
Is there a way to accomplish this without this coupling or untidiness??
No, not as far as I'm aware, #defines and NSString constants is where it's at and you can't get around having to include these in whatever file requires access to the string.
You could create header files for the different parts of your app, so you might have JJDocumentNotifications.h and JJViewNotifications.h for example. You could then #import them into your precompiled header (.pch) file, so the file looks something like this:
#import <Cocoa/Cocoa.h>
#import "JJDocumentNotifications.h"
#import "JJViewNotifications.h"
That way, the headers will automatically be included in all the files in your target and you won't need to import them specifically.