Cascade operator proposal — native fluent interfaces

# Timothy Johnson (a month ago)

I'm putting together a proposal for a cascade operator like the one in dart. I think it fits the javascript design space quite well. The popularity of method chaining APIs points to this being something the javascript community wants.

For example

foo
    ..a.b = c
    ..d()

Would be equivalent to

foo.a.b = c;
foo.d()

Or more accurately

(obj => {
    obj.a.b = c;
    obj.d();
    return obj;
})(foo)

The full proposal is at RedHatter/proposal-cascade-operator. Any thoughts?

Also, how do I go about getting this accepted at stage 0?

Edit: Fixed the formatting, sorry.

# T.J. Crowder (a month ago)

On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson <timothy at idioticdev.com> wrote:

It's great to see a proposal backed by an example implementation. :-)

I suggest adding some explanation to the proposal about how your example knows the ..d() applies to foo and not to c. From the Dart documentation, I'd guess (not being a Dart person) that it's because you'd need parens around the c..d() to force it to apply to that instead, but... More about the specific mechanics of that as it applies to JS would be useful.

Probably also worth a one-liner that you're aware of and have allowed for how this relates to numeric literals (e.g., console.log(12..toString())). I can see in your commit on the Babel fork that you have allowed for it, but for those who don't dig that deep...

If this were in the language, I'd happily use it. I don't really feel the lack of it, though.

-- T.J. Crowder

# Andrea Giammarchi (a month ago)

I have a dejavu ... a similar proposal was rejected a while ago.

Can't remember its name but it was like:

foo.{
  a.b = c;
  d();
}

how is this different, if it's actually any different?

# Timothy Johnson (a month ago)

I believe you're referring to web.archive.org/web/20160310120516/http://wiki.ecmascript.org/doku.php?id=harmony:object_literals#object_extension_literal? While my proposal is similar in theory, it does have a few differences in practice. Namely, object extension literals only update properties on the root object, they don't allow for function calls. The intended purpose of the two proposals are also quite different: object extension literal were intended to be used as part of the object creation process, the cascade operator on the other hand, while it can be used for object creation, the main focus is to ease using objects.

Furthermore, object extension literals where proposed 7 years ago. Long before jQuery and the rise of fluent interface popularity in the javascript community.

To summarise: A similar proposal was indeed rejected but the cascade operator has notable differences, and javascript is in a very different place then it was 7 years ago.

# Michael Haufe (a month ago)
# kai zhu (a month ago)

quick PSA:

jslint recently (2018-09-27) added warning against "." delimited, per-line method-chaining [1]

/*jslint node*/
"use strict";
var str = "hello world";

// jslint - no warnings
console.log(
    str.replace(
        "hello",
        "goodbye"
    ).replace(
        "world",
        "john"
    ).toUpperCase()
);

// jslint - warnings against "." delimited, per-line method-chaining
console.log(
    str
    // Unexpected space between 'str' and '.'.
    .replace("hello", "goodbye")
    // Unexpected space between ')' and '.'.
    .replace("world", "john")
    // Unexpected space between ')' and '.'.
    .toUpperCase()
);

[1] jslint commit 2018-09-27 - warn against per-line method-chaining douglascrockford/JSLint/commit/752c82d860ac14d35d492dc5c6ad0a0ed8227e76#diff-01d3d81a6eb6d82af3c377b55dc4fa28L4692

[image: Screen Shot 2018-11-13 at 11.06.26 AM.jpg]