5 ms·

Chainvas: a tiny library that can add chaining to any API like Canvas and DOM

17 points by aycangulez 15y ago

duncanbeevers 15y ago
Reminds me of node-chainsaw: https://github.com/substack/node-chainsaw https://github.com/substack/node-chainsaw Also, my own node-ContextChain https://github.com/duncanbeevers/node-ContextChain https://github.com/duncanbeevers/node-ContextChain Both of these libraries take the approach of wrapping the underlying object rather than modifying it.
wavephorm 15y ago
I've always thought the chaining methods thing that jQuery popularized was a pristine example of an anti-pattern. It might save a few keystrokes, but I question whether anyone really writes code like this the first time through. I suspect people actually take perfectly fine working code and refactoring it into a chain just to make the code appear more clever, all the while making the code harder to read and debug.
- deleted 15y ago
  [deleted]
- tikhonj 15y ago
  I like chaining because it emphasizes that a set of method calls is part of one discrete action involving one object. For example, take adding a header to some text: it's one action, but it involves multiple steps. First I create the actual element, then I give it a class name, add some text and finally insert it in the DOM. I think chaining not only makes the code easier to read (and type, although that isn't particularly important), but also makes its semantics clearer.
  - wavephorm 15y ago
    That's what functions are for. Chainable methods don't make multiple step operations more concise.
raganwald 15y ago
I applaud people for trying to find clean ways to add chaining to langauges like JS, but feel we are working at the wrong level of abstraction. Chaining is a syntax and grammer problem, not a semantic problem. Smalltalk solved this by making chaining part of the syntax. if you write: foo :bar; :bash something; :thenBlitz. The semi-colons tell the interpreter to chain the method calls to the original receiver. That way you can read the sntax and know chaining is involved without needing to know whether those methods were written to be chained. The return value of a method is its semantics, and should not be chosen to try to implement syntax. Summary: This problem should be solved by the parser, not by the function author. p.s. paging @jashkenas! p.p.s. Did you ever take that test yourself? Yes, my comments apply doubly to libraries like #andand.
- jashkenas 15y ago
  Reporting for duty... A dedicated syntax for chaining has been discussed several times for CoffeeScript, with different flavors: https://github.com/jashkenas/coffee-script/issues/1495 https://github.com/jashkenas/coffee-script/issues/1495 https://github.com/jashkenas/coffee-script/issues/1291 https://github.com/jashkenas/coffee-script/issues/1291 https://github.com/jashkenas/coffee-script/issues/281 https://github.com/jashkenas/coffee-script/issues/281 https://github.com/jashkenas/coffee-script/issues/1431 https://github.com/jashkenas/coffee-script/issues/1431 Personally, I'm a bit iffy on the subject, because although the demonstrated usefulness of the idiom is evident in libraries like jQuery, chaining-as-a-language-feature is inherently focused on stringing together a sequence of imperative side effects, where it can be nicer to use expressions for their values. For example, where the returned value is a part of the next step of the computation, chaining comes naturally: list .concat(other) .map((x) -> x * x) .filter((x) -> x % 2 is 0) .reverse() And where you need built-in language chaining to do the job for you, it's almost always because you're ignoring the return value, and using each method for its side effects: brush .startPath() .moveTo(10, 10) .stroke("red") .fill("blue") .ellipse(50, 50) .endPath() So the enforced imperativeness of chaining syntax makes it feel a bit off. Still, if you were designing such a syntax from scratch, and not following Smalltalk's lead, what would you think it should look like?
richbradshaw 15y ago
This website (much like all of Lea's work) has loads of really nice details – worth reading through the source code for anyone who works with CSS. Particularly the use of border-image, though there are a number of other nice little things going on here!

17 points by aycangulez 15y ago

Reminds me of node-chainsaw: https://github.com/substack/node-chainsaw https://github.com/substack/node-chainsaw Also, my own node-ContextChain https://github.com/duncanbeevers/node-ContextChain https://github.com/duncanbeevers/node-ContextChain Both of these libraries take the approach of wrapping the underlying object rather than modifying it.

wavephorm 15y ago

I've always thought the chaining methods thing that jQuery popularized was a pristine example of an anti-pattern. It might save a few keystrokes, but I question whether anyone really writes code like this the first time through. I suspect people actually take perfectly fine working code and refactoring it into a chain just to make the code appear more clever, all the while making the code harder to read and debug.

deleted 15y ago
[deleted]
tikhonj 15y ago
I like chaining because it emphasizes that a set of method calls is part of one discrete action involving one object. For example, take adding a header to some text: it's one action, but it involves multiple steps. First I create the actual element, then I give it a class name, add some text and finally insert it in the DOM. I think chaining not only makes the code easier to read (and type, although that isn't particularly important), but also makes its semantics clearer.
- wavephorm 15y ago
  That's what functions are for. Chainable methods don't make multiple step operations more concise.

raganwald 15y ago

I applaud people for trying to find clean ways to add chaining to langauges like JS, but feel we are working at the wrong level of abstraction. Chaining is a syntax and grammer problem, not a semantic problem. Smalltalk solved this by making chaining part of the syntax. if you write: foo :bar; :bash something; :thenBlitz. The semi-colons tell the interpreter to chain the method calls to the original receiver. That way you can read the sntax and know chaining is involved without needing to know whether those methods were written to be chained. The return value of a method is its semantics, and should not be chosen to try to implement syntax. Summary: This problem should be solved by the parser, not by the function author. p.s. paging @jashkenas! p.p.s. Did you ever take that test yourself? Yes, my comments apply doubly to libraries like #andand.

jashkenas 15y ago
Reporting for duty... A dedicated syntax for chaining has been discussed several times for CoffeeScript, with different flavors: https://github.com/jashkenas/coffee-script/issues/1495 https://github.com/jashkenas/coffee-script/issues/1495 https://github.com/jashkenas/coffee-script/issues/1291 https://github.com/jashkenas/coffee-script/issues/1291 https://github.com/jashkenas/coffee-script/issues/281 https://github.com/jashkenas/coffee-script/issues/281 https://github.com/jashkenas/coffee-script/issues/1431 https://github.com/jashkenas/coffee-script/issues/1431 Personally, I'm a bit iffy on the subject, because although the demonstrated usefulness of the idiom is evident in libraries like jQuery, chaining-as-a-language-feature is inherently focused on stringing together a sequence of imperative side effects, where it can be nicer to use expressions for their values. For example, where the returned value is a part of the next step of the computation, chaining comes naturally: list .concat(other) .map((x) -> x * x) .filter((x) -> x % 2 is 0) .reverse() And where you need built-in language chaining to do the job for you, it's almost always because you're ignoring the return value, and using each method for its side effects: brush .startPath() .moveTo(10, 10) .stroke("red") .fill("blue") .ellipse(50, 50) .endPath() So the enforced imperativeness of chaining syntax makes it feel a bit off. Still, if you were designing such a syntax from scratch, and not following Smalltalk's lead, what would you think it should look like?

richbradshaw 15y ago

This website (much like all of Lea's work) has loads of really nice details – worth reading through the source code for anyone who works with CSS. Particularly the use of border-image, though there are a number of other nice little things going on here!