I'm currently creating a site that has multiple color themes - it seemed natural to use LESS and #variables for this (using Wordpress / WP-Less). I soon realized I couldn't find a really clean way have only one, monolithical stylesheet, as, of course, after compiling variables can't be overwritten, and it's unfeasible to compile on every page render.
Creating separate theme stylesheets (which only contain the variable-modified values) seems to be the only way to go, but it will be somewhat cumbersome to maintain in the future.
I'm utilizing only 1-3 variables, but they are referenced many times.
Is it possible to utilize WP-Less/Lessphp to render multiple .css from one .less with several different variables changed?
Or is there a simpler / other standard way to achieve the above?
Less offers a way to modify variables at run-time:
Here's an excerpt from the docs online - http://lesscss.org/:
Modify variables
modifyVars enables modification of LESS variables in run-time. When called with new values, the LESS file is recompiled without reloading. Simple basic usage:
less.modifyVars({
'#buttonFace': '#5B83AD',
'#buttonText': '#D9EEF2'
});
Related
Sonarqube is displaying errors for empty css/scss files in the Angular application. What are the effects of having empty scss files? Do they cause issues with performance, side bugs/errors, future problems, what are the compound negative issues? These are generally leftover when we do ng generate component
Sonarqube flag: Remove this empty stylesheet
Article below states to ignore it, compiler will take care of it, however more interested in the effects of leaving empty files, if there are any.
Empty style (.css/.scss) files
Company would have to go through 1000+ empty scss files in large application, interested to know if its worth the time.
As far as I can tell from looking into this, the best answer is to just leave it. The compiler will indeed handle the empty files appropriately.
SonarQube is just picking it up as code smell, empty files should probably be removed to keep a project in its least complex state possible. In the example you gave with a company going through that many files it is a complete waste of time.
I come from the future and I face the same problem, our solution was to delete the files that were already empty and generate the new components with the --inline-style option, this way no css/scss files are created by default when create the components.
I'm writing a single-page JavaScript application and I'm using Atom as my text-editor. (It's an Electron application, but that's besides the point.)
I'm also using the linter-jshint plugin for Atom. This is great, as it shows immediately in the text-editor when I make a typo in a variable, among other useful things.
Lately, my app has been getting very long. Naturally, I want to try and split it up across multiple files. After doing some research on StackOverflow, I've determined that I can use Grunt to automatically concatenate JavaScript files together. This is great because I don't have to refactor my code - I can just copy paste my existing functions into separate files. Easy!
However, once I do this, Atom fills up with warnings and errors from JSHint, because it can't find variables and functions that are located in the other files!
Now, I could just abandon the JHint plugin in Atom altogether and use the JSHint plugin for Grunt after the concatenation has already occured. But that sucks! I want the code that I'm going to be writing to be checked on the fly like a real IDE.
Is there a way to tell Atom/JSHint to assume that a bunch of JavaScript files will all be concatenated together? Or am I just approaching this problem completely wrong?
You can split your electron application with Node Common Modules, and use require('./state.js'); within your application.
Although I don't use Atom, that should allow for it to understand how you're using your variables and functions in other files.
Also this should eliminate your need for concatenation as the single-page app will have all it's dependencies accounted for.
I'm building a simulation in Julia and I have my code split across a bunch of files. Are there any benefits to wrapping everything in modules versus simplying include()-ing them in the runscript?
I have something like the following at the top of my runscript right now:
for filename in split(readall(`git ls-files`))
#everywhere include(filename)
end
I'm not planning to use the code outside of this immediate project, but I am running the simulation in parallel. Is there any benefit in creating modules?
I would say that the most important benefit is modularity :)
If you have different files that deal with different things, splitting the code into modules let's you keep track on the dependencies between the modules:
Which functions are purely implementation details of the given module and subject to change?
Which modules depend on which other modules?
It also lets you reuse the same name for different things in the different modules if you need to, if you're a little careful of what you export. (You can still access those names from the outside as qualified names)
For an example of such organisation, you can look at my repo https://github.com/toivoh/Debug.jl
SHORT: Is there a possibility to import less files "on demand", only when the function/variable has not been defined yet?
LONG: Let's assume I have LESS file containing my styles for the page. Let's call it styles.less. In addition, I have 5 more LESS files. Everyone of there contains generic design primitives, for example design of the info box which I use in many projects - that's the reason it's not been merged to styles.less. Let's assume it's called .infobox {}.
Then, is it somehow possible to "try" to import that 5 files when .infobox is not found in styles.less? I'm interested in both compiling via lessc (module for node) and "on-the-fly" compilation in web browser.
I hope my examples clarify the situation enough - if not, feel free to comment and I'll edit the question to provide more information.
I have not been able to find a way to make this fully automated. I also do not know if you are desiring this functionality in order to reduce #import requests or to simply reduce the final CSS to not load items it does not need.
If you do not need it to be fully automated, and you are seeking just to reduce the CSS generated, and you do not have too many classes you desire to do this with, then you can do something like the following in your styles.less file.
//have at the top of the file some variables set to 0 or 1 if the class
//is present or absent in that file
#usesClass-infobox: 0;
//set up a mixin to load it if NOT in the file
.setClass-infobox(#set) when (#set = 0) {
#import 'infobox.less';
}
//a default mixin to do nothing otherwise
.setClass-infobox(#set) {}
//call the mixin
.setClass-infobox(#usesClass-infobox);
Of course, this does not really help automate the process. After all, if you know .infobox is not in the styles.less file, then you would just add the #import anyway without any extra mixins to check. The only real value this gives is that it sets up a section of variables that basically informs the coder that "Hey, there are modules that can be loaded for this functionality if you are not including it here; so tell me, are you including it?"
Again, I'm not sure if this totally resolves what you are going for. I offered it as it could be useful for some people in some situations.
How do you like to organize your Drupal code? One giant module? Separate modules per feature? Separate modules per code type (theme functions, menu hooks, etc...)?
I've started by trying to organize by feature, treating modules like they were libraries. Ultimately though things are never perfectly contained... modules want to use each other's theme functions, and modules are all contributing various tabs to a common page -- two examples of it not always being so clear where to find code. This tempts me to keep all theme functions together, and all hook_menus together, but this would be awkward for other reasons...
Assume that all code is too specific to eventually share, so there's no attempt here to make self contained contributed modules. I'm mostly concerned about maintaining sanity and cleanliness in a large scale Drupal site.
I tend to have a folder with one main module with all the shared functions, and a variety of sub-modules that are broken up by logical functional divisions. I've found the single huge module approach makes finding stuff in it rather unfun.
It really doesn't make much of a difference if you're not distributing it on Drupal.org, though, so whatever makes sense to you is fine.
I load all customizations into a single module per project (menu/form/link alters, etc.). If enough customization is done, I will fork the original module or create a new module with the original module as a dependency. It's at this point that it pretty subjective: I have no hard and fast rule saying 'fork a module when I reach this many function points or lines of code'.
Anything that adds functionality (meaning that it doesn't override something else) goes into it's own module.
If any newly created or forked modules can be used in other projects or contexts, I will publish them to my personal repository.
I most often use a single module and a set of include files where I store my classes. Although views uses more than one module, it is a great example of the this strategy. Take a look at the views module includes folder to see what I mean.