Many times I need to share css variables and mixins between files. What I have done, is just move variables into a separate file named 'variables.css.scss' and then
#import 'variables' to whatever sheets need 'em.
This works locally, because that separate file actually exists. But, after compiling assets (like on heroku) that file is no where to be found...triggering load path error.
Is there a way of keeping variables and mixins DRY?
#import is just like a partial. For whatever reason my local environment is not being as strict as the heroku API is (strict is better). All I needed to fix this was change the actual file name from 'variables.scss' to '_variables.scss'...just like a partial. Heroku is happy now...
Related
I read this:
If you add a dir directly under app/
Do nothing. All files in this dir are eager loaded in production and
lazy loaded in development by default.
If you add a dir under app/something/
(e.g. app/models/concerns/, app/models/products/)
Ask: do I want to namespace modules and classes inside my new dir? For
example in app/models/products/ you would need to wrap your class in
module Products.
If the answer is yes, do nothing. It will just work.
If the answer is no, add config.autoload_paths += %W(
#{config.root}/app/models/products )
I want to know how Rails does this. How does it:
Load the file inside a folder (named folder_nest) in the app folder only if the contents of that file are wrapped in a module named after that folder (folder_nest module). How does this happen?
There must be some logic that says: "if the thing inside of app is a file, eager load it. If it's a folder, only load the contents of said folder if it's wrapped in a module named after said folder."
Anyone know where this logic is? How do I read Rails source code?
Also, is config/initializers eagerly loaded? Where is that logic?
Well, looks like you have a lot of questions best answered by the one question "How do I read Rails source code"
Personally, I do something like the following from the command-line:
subl `bundle show rails`
and then use the text editor (sublime in this case, textmate also works) + search, just read the code. Sometimes I'll insert "puts" statements in there to make sure I'm reading the right code and run it just to be sure.
You can answer most of your own questions about the initialization sequence, etc, that way.
Is it recommended to refer to all my header file in Prefix.pch, and then I do not have to type #import headers during development?
I wouldn't recommend this.
The main reason is, header files can change in the course of your development. If you change one header, it will cause the pch to dirty, have to be rebuilt, and now your entire project will rebuild. That's quite time-consuming, and works counter to the whole reason for pch files.
Same thing if you create a new header file, add it to the pch, and now that triggers and entire rebuild.
But there's no single answer here. You may have a 3rd party library that will never (or rarely) change, is quite header-intensive, and so precompiling it may be a way to reduce build times. Experiment and see.
Pre-compiled header files were brought to serve one purpose: to make compiling faster. It is compiled and stored in cache, and automatically included in every source file during the compilation time. Its like each source file does,
#import "Prefix.h"
This can be handy for project-wide #defines. (FYI, #defines are a code smell)
Xcode quotes:
Precompiling the prefix header will be most effective if the contents
of the prefix header or any file it includes change rarely. If the
contents of the prefix header or any file it includes change
frequently, there may be a negative impact to overall build time.
More clear explanation is here
Please keep this in mind when you #import source file header in .pch. As a tip, you can use Prefix.h for #import of constants and utility source files.
From a standards perspective, your includes should be as minimal as possible. Indeed, you shouldn't include anything you don't require for compilation into any file. So, in each of your .h files you should primarily include the superclass and use #class for all other references, then include only in your .m files. This gives the clearest information about the requirements of each class / file and minimises circularity issues.
You should add header file to Prefix.pch just if you need that file/class in most of your other classes. If you need the header file just in one or two other classes it's not point to add it to .pch because it will takes more time for compiler to compile the files and it will happen every time you want to run your project.
I add all the headers to Prefix.pch, and I have to claim life is much easier since that time. I just do not have to import always headers, believe me, life is much easier. :-)
I am using Mogenerator to automatically create subclasses for my Entities in Core Data.
I had acted upon a recommendation I read to store the files in subdirectories within my project (since I will have many). Used the following arguments when running the script:
cd Project
mogenerator --template-var arc=true -m Project.xcdatamodeld/Project.xcdatamodel/ - M CoreData/Machine/ -H CoreData/Human/
I added these to my project as a folder reference, as the script may add files to match my model and I don't want to have to add them to my project manually.
The directory structure for both the created files are like this:
Project/CoreData/Human/Entity.h
Project/CoreData/Machine/_Entity.h
I need to import "_Entity.h" inside of "Entity.h". The problem is, it's not in the same or lower directory and I don't know how to do a relative reference to a higher directory. I'm forced to use an absolute directory all the way from /Users.. which works, but it includes my username etc. so I'd rather not.
Question: How can I import _Entity.h from Entity.h using relative reference?
Bonus question: Is it possible to have mogenerator automatically use the proper reference? I mean, I'm clearly telling it where to put both files and it's doing it, but still only puts the following in Entity.h:
#import "_Entity.h"
...and I get an error.
Thanks in advance,
Pat
".." (without the quotes) represents the directory that's "one level higher". Use this to go to "CoreData", then to "Machine".
Try this:
#import "../Machine/_Entity.h"
I'm not sure if it'll work, but it's worth a try!
I have two files:
black.less
/* imports */
#import "elements.less";
#import "crush.less";
#import "tree.less";
I'm using the less watch functionality by adding:
less.watch();
Sure enough I can see the traffic getting black.less. Black.less hasn't changed though so any change in any of the files being imported is not counted as a change and the style is not updated.
If I however touch black.less the style updates as it should.
Is there a way to automatically update regardless of if it's an imported file or the actual less file being added to the page i.e. so that I only have to change let's say tree.less.
/K
I use Grunt and the grunt-contrib-less plugin to watch all of my less files and compile them into CSS as they change.
Then I use live.js in the browser to watch the CSS files.
The advantage to doing it this way is that I can do the same thing with my HTML and JS files, as well as run tests, lint my JS files, etc.
Remy Sharp recently wrote a post about how newer versions of Chrome support the ability to save files that you edit in the dev tools back to the file system.
He advocates Never having to leave devtools. Just do your edits right in the browser. The advantage to this solution for you is that you could continue to use the client-side Less compiler.
(I still like my robust text editors and command-line too much to ditch them entirely, but thought this answer would likely appeal to at least a few people who arrived at this question.)
Here's another quick way.
watch -n 1 touch black.less
This may be too late for op, but I had the same question and maybe others have it too.
less-watch-compiler will watch a directory (and sub-directories) for changes and compile any less code to a destination folder. The cool bit is that you can specify the main file and only the main file will be compiled when any file in the source directory is changed.
Usage:
less-watch-compiler [options] <source_dir> <destination_dir> [main-file]
Sorry for the horrible question wording, let me explain.
For a project I'm working on, I'd like to manage various dependencies for my LESS files on the server. Because of the way the project is structured (different components symlinked in different ways), it's much more limiting to just use #import to build dependencies etc.
Ideally I'd like to just spit out a list of required LESS files in the section, e.g.:
<link rel='stylesheet/less' href='/path/to/some/file.less' type='text/css' media='all' />
<link rel='stylesheet/less' href='/path/to/some/other-file.less' type='text/css' media='all' />
Then, for example, if a variable or mixin is defined in file.less, I'd like to be able to use it in other-file.less.
From what I can tell, that doesn't work. Each LESS file seems to exist in its own scope and variables etc in one are not available in the other.
Is this correct? Is the scope entirely limited to a single file and any #imports therein? I'm reasonably sure that it is, but not entirely.
For now, my workaround is more complex than I'd like: I'm building dependencies server side, and then munging them into a giant, single development.less file on the fly. (Note that for production purposes, I have a build process that compiles and minifies my less so that I serve straight up CSS).
I've looked at browser.js in the LESS source code for clues but thought I'd ask here first if this was possible or even desirable. I was a bit surprised at this behavior since it's not how multiple javascript files and inline code work.
Why It Doesn't Work
Each <link> of a LESS file preprocesses that file and resolves it to just a plain CSS output. No variables or anything are left in the "scope" of the html itself, so there is nothing for the second <link> to be able to use. That is why one cannot read the other.
A Possible Help
With LESS 1.5 an #import can be made to just be a reference (and thus not compile direct output into the file). So your other-file.less could do this:
#import (reference) file.less;
To gain the dependencies needed for it.