Feedbacks

[lexich]

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

[lexich]

And i publish es6 compiled code for you. Almost the same as I would write if i used typescript

[ai]

Smart move. It it works only for new nodes. Not for changing exist nodes:

decl.parent.nodes[0].selector = 'a' // it should trigger plugins again

[lexich]

Ok. Workaround: at this moment all visitors applies for each node, but we can apply for each visitor all nodes. And this node will have refs of current visitor. But complexity would be the same. And It helps reduce additional check loops.

[ai]

Sorry, I didn’t get how it will fix problem. Here is example:

Our CSS is:

a {
  width: 100px;
  magic: width;
}

We have 2 plugins: postcss-calc and postcss-magic. They was applied to width and both ignored this declaration. postcss-calc was ignored magic declaration. but postcss-magic was execute callback:

decl.prev().value = 'calc(300px - 100px)'

Now our CSS is:

a {
  width: calc(300px - 100px);
  magic: width;
}

In this case we need to run all plugins on changed to width (to apply calc() plugin).

How do you plan deal with it?

[lexich]

Order of plugins (visitors) is very important. We need to change order. First of all apply postcss-magic and after that postcss-calc. It's normal behaviour.

[ai]

It will not help.

1. postcss-magic was ignore width, postcss-calc was ignore width.
2. postcss-magic changed previous declaration (width), postcss-calc ignored magic.
3. the end

[lexich]

Yes it's current behavior. But new plan. postcss-magic: 1. Ignore width 2. change declaration. postcss-calc: 1. convert calc 2. Skip magic
check loop. End

[ai]

You want to run all AST loop for every plugin? But main point for this Event API is having 1 loop for all plugins. It will increase performance.

Loop-per-plugin is already in PostCSS API and works slow.

[lexich]

No. Complexity will be equivalent. N - nodes M - visitors.

for (n of N)
   for (m of M)
      f(n,m)

is the same

for (m of M)
   for (n of N)
      f(n,m)

In current plugin system works as

for (m of M)
   for (n of N) //eachDecl
      f1(n,m)
   for (n of N) //eachRule
      f2(n,m)
   ...etch

[ai]

@lexich you don’t need to use eachDecl. walkDecls give you same

for (m of M)
   for (n of N)
      f(n,m)

[ai]

I checked latest node and seems like they change console.log behavior. Now it displays getter/setters in correct way. So we could mark nodes as dirty by ovverride all node method and set getters/setters.

[lexich]

@ai hmm. Latest node it's ok, but other nodes and browsers have problem with full support proxy. in current master one test fails on node 4 (polyfill) and pass on node 7. In other hand Proxy is slow and it may downgrade current performace.

Other way without proxy is very like on current plugin system and can be short to this snippet.

css.walkQuery({
   decl: {
      enter: (node)=> node.color = 'red';
   }
});

But in my sense it'll have profit only if you write you plugins very unoptimize way.

As the result we can add new syntax for writing queries, without performance profit (but of course without benchmarks it very hard to say about it), of course if it'll be interesting for project.

[ai]

Let’s just add getter/setter for each Node property