Discuss
  • Cascade operator proposal — native fluent interfaces

Cascade operator proposal — native fluent interfaces

# Timothy Johnson (6 years 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 (6 years 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 (6 years 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 (6 years 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 (6 years ago)

It didn't survive the github migration AFAICT. There is no proposal listed on the repo.

web.archive.org/web/20141214124428/http://wiki.ecmascript.org/doku.php?id=strawman:batch_assignment_operator

esdiscuss.org/topic/batch-assignment-functions

rwaldron/tc39-notes/blob/master/es6/2012-05/may-23.md#moustache

# kai zhu (6 years 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]