Feedbacks

[lexich]

Task description: http://cultofmartians.com/tasks/postcss-events.html

[lexich]

@ai What do you think about this syntax stream-api and early reference implementation?

[ai]

Could you show some examples or links?

[lexich]

implementation postcss-color-function
unit-test

[ai]

query callback and fn?

Hm. Babel use shortcut like:

decl: {
  enter: decl => {
    if (otherCheck(decl)) {
      doSomething(decl)
    }
  }
}

I think this syntax is more compact and still flexible. What do you think?

[lexich]

Yes, current syntax more verbose and of caurse need to improve.
But I think to allow more complicated expression. Maybe more shorten variant?

createStream([{
   // this means than we match expresstion atrule > rule > decl according query composition
   decl: [<query>],
   rule: [<query>],
   atrule: [query],
   enter: node => {

   }
}, {
 ......
}])

But another hand, some shortcurts also good.

[ai]

What type of query you want? Could you show some examples?

[ai]

Or query is just a function?

I think it is still more complicated than 1 function (because 2 functions is more complicated than 1 :D ) and longer.

Why you prefer this syntax with separated query and change functions?

[lexich]

Hmmm.
<query> in my sample can be string, regexp, function, array of string (or/and) regexp. Also may be add shortcut for indexOf.

I thought about your questions and what do you think about improvements in DSL like these.

createStream([{
  decl(node) { 
    // match all decls
  }
}, {
  decl: {
    prop: "width", // or may be function, /width/, ["width", "height"], [/width/, "heigth"] etc.
    value: "100px",
    enter(node) {
      // match all decls with prop "width: 100px"
    }
  }
}, {
  rule: {
    selector: /.test/, // maybe string, function, like example above ,
    decl(node) {
      // match all decl under the rule
    }
  }
}])

I think that this concept like your suggestion and also show my idea of nested queries and of course less complicated

[ai]

Note, that enter is part of enter/leave paradigm.

For example, we have rule a { … }. Some hooks should be executed before processing declarations inside. Other should be processed only when all hooks will finish working inside.

As result, if we have this css: a { color: black }, events will be:

• enter a rule.
• enter color decl.
• leave color decl.
• leave a rule.

[ai]

OK, I am OK with this queries.

What if you need to check other nodes inside with “event listener”? Or we could ignore this case, because we will have event API and old AST API for simple cases (most of custom Stylelint rules could not be written on event API).

@ben-eb @davidtheclark what do you think about this API?

[lexich]

.test { width: 0px; }

createStream([{ 
    decl: { // step1
        prop: "width"
        enter(node) {
            node.value = "100px"
        }
    }
}, {
    decl: { // step2
        prop: "width",
        value: "100px",
        enter(node) {
            node.prop = "height";
        }
    }
}, {
    decl: { // step3
        prop: "width",
        enter(node) {
            // won't perform
        }
    }
}])

Also I wanted to mention that steam listen node modification.
step2 will be execute because step1 fix node value and step 3 won't because step2 changes prop. Also node can be processed or skip by walker only once, independs from it's state.

[ai]

@lexich yeap, changes listening is a great feature. Same with inserting new nodes?

[ai]

@ben-eb right now I am thinking to always keep non-event and event API. Main reason — writing a Stylelint rules should be extremely easy. But all my experience with event parsers (like SAX for XML) told me that event-based API is very complicated. It is much easy to write XML tool on top of DOM, instead of SAX.

In other hand only few PostCSS plugins are really popular. So we could move only slow or popular plugins to event based API (Autoprefixer, CSS Modules, css-loader, cssnano, PreCSS, core Stylelint rules, postcss-inline-svg, postcss-assets, postcss-sprites, RTLCSS).

In this case, I think we could be from doing 100% things in event based API. For example, we could not have API for creating a visitor in visitor (like Babel does, more complicated thing to understand).

[lexich]

@ai yes, to wrap all mutation operation. I have already made this for value property https://github.com/lexich/postcss-stream/blob/master/src/overwrite.ts