I’m a fan of micro libraries of sort. Instead of hoping for one framework to do everything (especially, if there’s basically one guy trying to maintain that everything), I’d rather use another lib that’s solely focused on the task at hand. It’s a line drawn in sand of course, which components to include in a framwork and which to exclude… I think it’s great the community can & has provided additional components for SUI, such as the date picker!
When a framework tries to include everything, this kind of things tend to happen:
I wanted to use the form styling of Semantic-UI, but to handle the validation with ViewModel’s validation tools. If I include the form-element in my SUI build, it automatically includes a lot of form related JS in the SUI bundle, which I don’t need. That can easily go unnoticed, until you find out your JS bundle is 3Mb in size.
I guess the lesson that could be learnt here is, that with a huge framework such as SUI it is essential to provide the different elements, options, variations as opt-in rather than forced upon. Now it’s a lot of trouble trying to get rid of stuff that’s not needed, like form validations, popups, all the 15 different color themes for everything etc…
It is very slow, as it’s basically rebuilding SUI every time you change any file on the client. At least it used to, I don’t know with the latest speed improvements in the build tool or possible improvements in the package. Especially if you’re not making any changes to SUI, you could get huge performance improvements by creating a separate project for SUI that builds the .css and .js bundles for you to include in a Meteor package.
Actually this is possible, but I need to add it to the documentation - sorry about that!
Since you’re using SASS, the variables are interpreted by SASS instead of PostCSS - use the globalVariables option instead:
The reason for that message is that I haven’t tested node-sass version 4 yet, and the major version bump signifies potentially breaking changes. I don’t want users to get stuck if node-sass changes their library in a way that prevents my package from working with it. I’ll think about adjusting the message and think about the frequency, though.
Thanks, awesome! I was about start filing a pull request to fix an error in the docs regarding where those globals should be defined, but apparently they just work differently based on the key in configs.
I’m still trying to orient myself to this new paradigm, and one thing I find confusing is triggering animations with classes.
Say I used to do something like this (the class is assigned by a ViewModel binding based on the value of isBacksideVisible )
I tried this, and this type of error appears in my console:
=> Started proxy.
=> Errors prevented startup:
While processing files with nathantreid:css-modules (for target
native: Cannot convert undefined or null to object
at hasOwnProperty (native)
at loadPlugins (packages/mss/postcss-plugins.js:50:5)arggh
at new CssModulesProcessor (packages/mss/css-modules-processor.js:27:27)
=> Your application has errors. Waiting for file change.
With the same config as above, except the globals defined in fileOptions instead, this doesn’t work as I thought it would:
composes: b from ('./utils.m.css');
I get this error:
Processing Step: CSS Modules / PostCSS compilation
Unable to compile /Users/arggh/Development/modulesapp/client/styles/shared/input.m.css
CssSyntaxError: postcss-modules-scope: /Users/arggh/Development/modulesapp/client/styles/shared/input.m.css:2:3: referenced class name "b" in composes not found
composes: b from ('./utils.m.css');
I’ve filed an issue for the Cannot convert undefined or null to object error.
The issue is occurring because you are using postcss-simple-vars with the globalVariables option and without specifying any configuration for the postcss-simple-vars plugin. That’s a scenario I hadn’t anticipated.
For now you can workaround the issue by supplying a fileOption to postcss-simple-vars; even an empty file will do:
If you’re still using SASS but specifying the global variable in the postcss-simply-vars configuration instead of the globalVariables field, I’m surprised it’s getting that far. I’d have expected it to error out when node-sass ran.
It sounds like PostCSS is experiencing issue compile utils.m.css, but isn’t spitting out an error for that. Can you create an issue on Github and if possible supply a reproduction repository?
I’ll have to push the animation example off to tomorrow since work ran late tonight. I do agree on the documentation / samples, though. I’ve started work on a non-React SCSS example. It’s very basic right now, though - just a conversion of my basic CSS demo: https://github.com/nathantreid/meteor-css-modules-demo-scss
@jlukic , I guess you can already consider your “goal” with Semantic-UI accomplished in a sense
[quote=“arggh”]Actually, I just realized that using CSS Modules, I can get rid of Semantic-UI, but keep the natural language with composes and achieve really atomic and reusable CSS like this:
That’s pretty much how I would have done it, and I LOVE composition especially for pulling styles from frameworks like bootstrap as well as reusable application-wide styles like you posted. The only thing I’d have added to what you posted is the caveat that although this seems to be the official CSS modules way (one “class” at a time per element) I don’t adhere to this when I start to accumulate lots of variations on a particular element. For example, if I need to flip the card, or make it purple, or both:
About the time I get to flippedAndPurpleCard I start to really think about how many variations there might be, and whether or not I’m better off composing them the CSS Modules way shown above or dynamically in my code (this was all typed directly on the forum, so although it’s based off of actual code it may not be 100% correct):
import styles from './card.css';
let styles = [styles.card];
return styles.join(' ');