Google Material can be customized with just a SASS sheet. Sadly, wrapper libraries break that. Let's unbreak them.
npm install -g immaterial immaterial yourrules.json
You should now see
You may create a
yourrules.json by copying
lib/material defaults.json to the main directory, configuring the
rules you're interested in, and if you like, removing the others.
What's this all about then guvna
So maybe you're at a company that uses more than one frontend strategy - say,
React (or vanilla and
Riot, or ... eh.)
And, y'know, at one point people will make the correct observation that UI unification is a Good Thing™. And they might, sensibly, think Google Material is a good approach to solving that, because ostensibly it's a nearly pure CSS approach, and that means portability, and yadda yadda. And a cheer will go up among the devs, and everyone will get emotionally committed.
Then the real world hits.
See, kids, there's only two complete
React solutions out there, and only one complete
Angular solution, and of course
they're not the vendor ones. And of course they're written by people who think that if you're using their solution, then
your entire company is committed to that frontend tech, and they can just break the CSS thing without consequences.
Which, of course, has consequences.
Why I oughta
You don't have to. I already did.
Immaterial. Because that's into what I'm trying to turn this problem. (Woo tortured sentence structure! Wooo.)
The idea is simple.
- Tokenize all the rules that can be represented
- Make a tiny pluggable build system (aww lookit it's so cute)
- Consuming one meta-stylesheet, produce N outputs
- Pre-offer outputs for:
CSS) style SASS rulesheet
React) style imperative API
angular) style imperative API
immaterial is MIT licensed, because viral licenses and newspeak language modification are evil.
Free is only free when it's free for everyone.