DRYing Rules about atomizer HOT 11 CLOSED

I think this is a great idea. I'm not really sure how useful it is to allow users to set custom rules though.

Thoughts @src-code ?

from atomizer.

I think there's value in having developers create custom rulesets (eg, for helpers), but I don't expect developers to dig into our rule file and make edits all that often. So I think there could be value in doing this, though I'm not sure what the priority should be. Let's mark this for our 2.1 milestone for now.

from atomizer.

@src-code I don't think people would want to add custom rules on their apps directly but I see that as Atomic gets more popular this kind of feature can be used by 3rd party to create atomic extensions.

For now the main goal of this suggestion is to remove code duplication from rules.js and make it easier to maintain.

from atomizer.

also this would allow to have the rules split in different files, e.g:

// rules/index.js
Atomizer.setRules(require('./padding.js'));
Atomizer.setRules(require('./margin.js'));
...
Atomizer.setRules(require('./colors.js'));
...

module.exports = Atomizer.getRules();

from atomizer.

In the end what Atomizer.getRules(); will return will be the same and no other file would need to be changed.

from atomizer.

I am not thinking about people editing our rules directly instead they could create a node_module that simply add new rules to atomic. If someone wants those extra rules they just have to install that module.

from atomizer.

This suggestion is related to #90

from atomizer.

Yeah, I like the idea of this one, we'll just want to think through the implications of this change (eg, in which cases would not want to inherit settings from the parent?) We definitely need a way in 2.0 to allow developers to add in multiple rulesets. I'm intrigued by the pattern you've suggested here (of calling Atomzier APIs from within each rule file) but suspect we may want the rule files to be less dependent on Atomizer, especially since getRules() would seemingly return the aggregate ruleset, so you'd have a harder time just loading a single ruleset for introspection...

from atomizer.

@src-code that can be simple, bellow there is a example of how we can implement this:

// Atomizer.js

module.exports = {
    _map: {},
    _list: [],

    // the argument is a simple array
    setRules: function (rules) {
        // Sets all given rules
        rules.forEach(function (rule) {
            this.setRule(rule);
        }, this);
    },

    setRule: function (rule) {
        // Inherit from the parent object or from a new object
        var parent = this._map[rule.parent] || {};
        var newRule = Object.create(parent);   

        // Overrides from the parent properties
        Object.keys(rule).forEach(function (key) {     
              newRule[key] = rule[key];              
        }, this);

        // Pushes the newRule to _map and to the _list
        // Some logic can be added to make sure the same rule is not added twice 
        // or to replace an existent rule
        this._map[rule.id] = newRule;
        this._list.push(newRule);
    },

    getRules: function () {
        // returns all rules as a list this output is an array of rules, the same as what we currently have.
        return this._list;
    }
};

The object above allows us to easy add new rules, we can add rules provided from separated files or from configs we can add some settings to allow certain rules to be overwritten or to prevent that to happen... It is very flexible and easy to maintain/improve.

from atomizer.

the rules.js can be very simple and clean too:

// rules/index.js
[
   'padding',
   'margin',
   'position',
   ...
].forEach(function (file) {
    Atomizer.setRules(require('./' + file));
}); 

// This will return exactly the same as the current `rules.js`.
module.exports = Atomizer.getRules();

Each rules definition file exports just a simple array similar to what we have but he can use inheritance:

// rules/padding.js

module.exports = [
 {
        type: 'pattern',
        id: 'padding',
        name: 'Padding (all edges)',
        prefix: '.P-',
        properties: ['padding'],
        allowCustom: true,
        allowSuffixToValue: true,
        rules: [
            {suffix: '0', values: [0]},
            {suffix: 'inh', values: ['inherit']}
        ]
    },
    // top
    {
        parent: 'padding',
        id: 'padding-top',
        name: 'Padding top',
        prefix: '.Pt-',
        properties: ['padding-top'],
    },
    // end
    {
        parent: 'padding',
        id: 'padding-end',
        name: 'Padding end',
        prefix: '.Pend-',
        properties: ['padding-$END'],
    },
    ...
];

As you can see this architecture will make much easier to create new rule files or to load rules from configs. By reading rules from a config we allow custom helpers, plugins and a lot of extensions built by the community ;)

from atomizer.

About inheritance, on the exemples above it is optional. If you dont want to use the parent you dont have to, in that case you just need to define all props of that rule, just like we currently do.

The performance and memory consuption is better too because by using object inheritance we are not copying duplicated props, each object only defines what it has diferent from its parent.

from atomizer.