I have the Less package loaded in my Meteor application and it is working fine. Now I need to allow the users of my app. to override my less variables. I have looked at :
less.modifyVars({
'#canvas': '#5B83AD'
});
but my app. is saying that 'less is not defined'. Can someone suggest how this can be done?
Less files can only be modified up to the point they're compiled to css files. This happens when you deploy your Meteor app.
It's not possible to change less variables at runtime. You would have to manipulate the DOM instead. Jquery is able to do this by targeting the DOM elements you want to change. You would have to tag them with a class.
An approach this way make work for you:
<div class="canvas"></div>
Then you could edit it at runtime using Jquery:
$(".canvas").css({background: '#5B83AD'});
Edit: I think the code you're refering to is the less.js client side file from https://github.com/less/less.js/. There's a bit more info under 'Client side usage' on http://lesscss.org/
This is a bit different from the Meteor less package, which is exclusively a server side compiler during development.
If you downloaded the less.js file (from https://github.com/less/less.js/archive/master.zip) and placed it in your /client/compatiblity folder you could use it in the way you wish. Keep in mind you may have to remove the Meteor less package since you want to load them raw, you will also need to reference them manually as Meteor will ignore the less once you remove the less package.
Related
I'm using CSS Modules (Sass) with rollup on a component library project, which is working well. Each component ends up with a dist folder containing a single JS bundle file, and a corresponding CSS file with the scoped CSS classes so consumers of the component don't have to worry about CSS class name conflicts. All they do is include the JS bundle and the CSS file and everything is great. Yay CSS Modules.
The problem I'm now facing is that some components really need separate "themes" - ideally, separate CSS files, one per theme. So consumers can continue as they've been doing: including the JS bundle, but now choosing which CSS file to include to pick a theme.
I'm not sure how to get this going with CSS modules & rollup, and whether this is even the sort of approach others are taking. From what I can see, rollup always handles bundling things together, whereas I want separate CSS files, all of which get their classes renamed identically during the build phase. That way, if within my JS I refer to styles.myclass, if myclass had gotten renamed to scoped-myclass by CSS modules for the original CSS file, for a second CSS file it would also get the same name.
This would keep consumption of the component extremely simple - just a matter of including a different CSS file.
Any suggestions?
Awfully late, but let me answer this 3 years on. So what I ended up doing was totally detaching the CSS generation step from rollup and relying on the Sass CLI to handle that portion of the build process. It felt a bit klutzy, but I remember it wasn't awfully hard to do and solved the problem I outlined above. I don't believe there was a plain rollup solution at the time, nor do I think there's one today.
However... in my case the whole approach was kinda mistaken. This certainly won't be everyone's scenario, but let me spell it all out because hey it may be useful and it definitely wasn't obvious to me at the time.
This was for an in-house shared component library, where each component and its corresponding CSS was a separate npm package stored in our Artifactory. When it grew, plenty of internal references popped up, e.g. multiple components would reference the Button component, and over time they'd reference different versions of the Buttons component - each of which needed its own properly scoped CSS, unique to that package-version.
So what I found was that by doing it this way - having the CSS generated as part of the npm package dist files - I had to write an additional layer for the consumer applications that would parse their node_modules/ folder for our own internal components and combine all the different CSS files, such as the multiple versions of buttons. e.g. the main application would directly import buttons v1.0.0 in its package.json file, but the Dialog component (also included in the package.json) could include buttons 2.0.0 as its own dependency. For every version of the package, there was a uniquely scoped version of the CSS - so the consuming application HAD to include every version otherwise the styling would be borked.
So all in all, it ended up being way more complex that I wanted. I thought I could make it easier & better with the separate generated themed CSS files as part of the package dist, but it didn't end up that way. If I could revisit that project today, I'd re-examine a solution used by Material UI and others which I kinda poo-poo'd at the time: automatic injection of the CSS into the page by the component JS, rather than generating standalone CSS files which required extra work by the consumer applications to gather up and add to the final webpage. Frankly, now I regard it as the "least crap". There are definite downsides to the injection approach (extra work done on every page render for everyone! Yikes!), but there's no doubt in my mind it hugely simplifies the job of the consumer applications. It's a balancing act, but in 20-20 hindsight I'd lean towards the injection approach. With that, scoping & theming is a different and much simpler problem.
If I got you right, consider looking at SCSS plugin: rollup-plugin-scss. It captures all spare .css files imported in the components, and then processes them through underlying node-sass. The catch is, it seems like you can write a custom callback function that'd handle your CSSs differently based on conditions you throw in.
Based on the example from the plugin's page:
import scss from 'rollup-plugin-scss'
...
export default {
input: 'src/index.tsx',
output: [...],
plugins: [
...
output: function (styles, styleNodes) {
// replace this with conditioned outputs as needed:
writeFileSync('bundle1.css', styles)
writeFileSync('bundle2.css', styles)
},
]
}
I'm working on theming a web app, and I ran into a problem with an angular directive that is being used. It's called angular-knob, and it uses an HTML5 canvas to display a progress bar input. Since it's a canvas, you have to tell it the color in JavaScript instead of CSS. This is the problem.
The rest of the site is themed based on a set of LESS variables. I would like the canvas to be the color of #brand-primary from the variables.less file, which could also be overridden in other theme-*.less files. I haven't found a good solution to this yet, but these are some of the ideas I've had:
Parse the variables from the LESS file with some kind of ASP.Net utility (haven't found anything that would do this for me) to get the variable names and then render them to the client in a JavaScript variable (which I could then put in an angular service)
Have gulp parse the variables from the LESS file (again, haven't found any npm packages that would do this for me) and create a script that puts the variables in with the JavaScript bundle.
Like I said, I haven't found any LESS file parsing utilities for ASP.Net or npm that would get me access to the LESS variables.
How would you tackle this kind of problem? Has anyone else had to handle something like this?
As stated by Rob Dodson, style tags are now unavoidable with Web Components. I am trying to find a way to use LESS with this new tecnhology without having to paste the compiled CSS in my HTML document everytime I change something in the LESS file . Is there anyway to achieve that?
I am using Polymer.
Thanks!
Laurent
You can make the client compile the LESS to CSS , you should definitely take a look at this :
http://lesscss.org/#client-side-usage
It is advised to compile it yourself to css in a production environment though !
Doing this client-side hardly seems like the corrent solution, especially at scale. For instance, do you really want 1000 web components in your app all including LessCSS and compiling on the client side?
Just compile server-side and include the compiled version in your html import. Apps like DocPad, make this a lot easier. For instance:
src/documents/components/my-component/my-component.css.less is your source file, and is compiled to out/components/my-component/my-component.css, which is accessible at /compoennt/my-component/my-component.css.
We use this workflow to also make use of javascript pre-processors like coffeescript, as well as post-processors like css auto prefixer, and bundlers like Browserify. See: https://stackoverflow.com/a/23050527/130638 for more info.
Simply compile your less and embed the generated CSS file via good old link tag.
I don't think that rob wanted to say that using style tags is the only way to go. You can still link to external stylesheets as you always did.
Why don´t you compile on server side using php compiler? Have a look here - http://leafo.net/lessphp/ -
To let you know, i´m using this compiler on my projects, on the server side without any kind of problems!!!!!!! :) IMO, it´s better to have the compilation work on the server side. I´m not totally 100% sure, but i think IE8 don´t recognize text/less
The way I have done this before is have individual .less or .scss file for each component and have it compile into the individual .css file which is then called into the respective component file. and finally vulcanize everything into a single file.
Incase you want to use a single CSS file, then use //deep// combinator or ::shadow pseudo elements in the CSS.
If you able to create the custom elements without using ShadowDOM then you can simply have all your less merge into a single CSS.
Honestly speaking I was unable to create a wc without shadowDOM in polymer. There is a long conversation on github on enabling / disabling and hacking a way to create a wc without shadowDOM here https://github.com/Polymer/polymer/issues/222
One solution would be to have the preprocessor translate .less files into .css and then linking them inside Polymer components, like explained in the official documentation: https://www.polymer-project.org/1.0/docs/devguide/styling#external-stylesheets
Unfortunately this is deprecated. So the other way to go could be to have another step that wraps the preprocessor-generated css files with a dom-module: this way you can follow the Polymer way including the style module inside your components, or using the css file compiled from less if you do things outside Polymer components.
I'm using Gulp for my build process and I found this module very useful:
https://github.com/MaKleSoft/gulp-style-modules
It creates, for every .less file I have in my sources, an .html file with a dom-module wrapped around it, ready to be included in the components' styles.
I don't need jquery in my meteor app. When I type meteor remove jquery, answer is jquery: not in project.
But jquery is still attached in html.
Meteor internals (domutils) depends on JQuery, but I believe the plan is to remove that dependency at some stage:
See: https://groups.google.com/forum/?fromgroups=#!topic/meteor-talk/21y9NbM9v90
Domutils seems to be able to cope without jQuery if sizzle is present (see findAllBySelector).
Doing a quick scan of the code I didn't see any other uses (other than on the server side - in the less parser).
To remove/replace jQuery with another version (2.x or 3.x).
Clone jquery package from official sources into your project folder /packages.
Replace contents of jquery.js with anything.
Downloaded package will have a higher priority and will be used instead of original one. Do on your own risk.
This is how I remove jQuery from Meteor.
Make sure your code really doesn't depend on jQuery before doing this. Also adding any Meteor packages depending on jQuery won't work as expected anymore (e.g: materialize:materialize).
So, if you want to make sure jQuery is removed from Meteor no matter what, just put
Package.describe({
summary: "Remove jQuery from meteor",
name: "jquery",
version: '1.999.999',
});
into packages/jquery/package.js. No need to clone. No need to add any other files.
Check your .meteor/versions file for the entry:
jquery#1.999.999
to confirm it worked.
In the Meteor FAQs http://meteor.com/faq/how-do-i-package-a-new-templating-system there is some information about adding a different (than the default Handlebars) templating system. Jade is the only other example explicitly called out elsewhere in the docs.
So is somebody already working on Jade? If not, is it feasible for me to start? Or is it still too early? e.g. :
The package API is rapidly changing and isn't documented, so you can't
make your own packages just yet. Coming soon.
I've been trying to love Handlebars in my current Ember.js project, but for me nothing is as elegant as Jade.
We would love to see Jade integration. Use packages/handlebars as a template.
The basic strategy is to wire the output of the template engine into Meteor.ui.render which is how we implement live page updates. As long as your template returns HTML, that'll work. Any time a Jade template references a Meteor.Collection document or Session variable, Meteor will register that dependency so that knows to rerender the template when the data changes.
Even better, though, is to also use Meteor.ui.chunk and Meteor.ui.listChunk. These will limit the amount of recalculation Meteor has to do when there's a change. For example, if you are rendering a list of documents using {{#each}} in Handlebars-speak, there's no reason to recalculate the whole template when a new document enters the result set. We just render one HTML chunk for the new document, and insert that right into the DOM. That's listChunk in action.
So you'll likely find that instrumenting just if/unless and for/each in Jade gets you a long way there.
Just be aware, package development is not as documented as the other parts of the system. So don't hesitate to ask more specific questions as you go.
meteor >= 0.8.0
Using the mquandalle:jade package has been officially recommended.
meteor <= 0.7.2
If you are not using CoffeeScript, you should check out jade-handlebars. As of this writing, there is an issue where CoffeeScript template files seem to need to be wrapped inside a Meteor.startup function which caused other issues for me.
If you are using CoffeeScript, you should check out my Cakefile. The details are all in the description, but the short version is that it automatically adds/removes/updates html files alongside your jade files. I ended up adding *.html to my .gitignore, which only works if you are not mixing html and jade in the same project. It's a bit of a hack but so far it's working fine for me.
Just publish my first meteor smart package on Atmosphere!
Use Jade+Handlebars instead of HTML+Handlebars
https://atmosphere.meteor.com/package/jade-handlebars
Just got jade templating working with my Meteor projects! And it is actual jade not jade-handlebars or some half form of jade. It is great but it needs Meteor UI which is currently in a development release called blaze-rc1. So it does not work with Meteor 0.7 at the moment.
do 'mrt add jade'
&
Run your meteor project using 'mrt --release blaze-rc1'
https://github.com/mquandalle/meteor-jade/
If you have coffeescript and jade files in the same folder add _ to the beginning of the file name so it loads jade files before the coffeescript file, otherwise it will not work correctly.
mrt add jade
in client/views/templates/hello.jade you could do something like this:
template(name="hello")
h1 hello world!
{{greeting}}
input(type="button" value="click")
start you app with mrt