Further improve method chain breaking heuristic

[thorn0]

fixes #3594
fixes #3621

A continuation of the work started here: #6685

A method chain now is always split onto multiple lines if:

• it's an expression statement and all its arguments are literals or UPPERCASE_CONSTANTs (the "fluent configuration" pattern),
• any call but the first one has more than two arguments, or
• the chain starts with a constructor call.

✨Try the playground for this PR✨

To install it locally, run npm install thorn0/prettier#tweak-method-chains

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
• (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/pr-XXXX.md file following changelog_unreleased/TEMPLATE.md.
• I’ve read the contributing guidelines.

[sosukesuzuki]

oh playground link not found....

[sosukesuzuki]

looks good

[thorn0]

Should we probably check the total amount of arguments instead (>= 6)?
This hardly deserves splitting:

a = foo.bar("netlify", "what happened", "to previews?").baz().qux();

[sosukesuzuki]

sounds good, but I think 6 is too much.
I want this code to be broken:

a = foo.bar("netlify", "aaaaaaa").baz("fooaaoooo", "baraaaarr", "bar").qux();

I missed some behaviors

[thorn0]

"at least one call with more than two args" && "at least one other call with more than one arg"?

Or maybe: "at least one call with more than two args, but this call shouldn't be first in the chain"?

[sosukesuzuki]

sounds good. if you push the implementation for it, I'll try it with various codes.

[thorn0]

pushed "at least one call with more than two args, but this call shouldn't be first in the chain"

[sosukesuzuki]

What about this? I found this when I ran Prettier 2 on a project in my company. It looks ugly for me.
Playground
Input:

cy.get(".ready")
  .should("have.text", "FOO")
  .should({ have, color, aaa });

Output:

cy.get(".ready").should("have.text", "FOO").should({ have, color, aaa });

Expected(same as input):

cy.get(".ready")
  .should("have.text", "FOO")
  .should({ have, color, aaa });

[thorn0]

@sosukesuzuki My last take away from #7884 is that we probably should always break chains used as expression statements. What do you think about it?

[sosukesuzuki]

@thorn0 Sorry if I make any mistake. "always break chains used as expression statements" means it breaks this code, right?

// Input
foo.bar().baz();

// Output?
foo
  .bar()
  .baz();

It looks overkill for me...

[thorn0]

@sosukesuzuki Do you have examples of real code that would look bad if we used this rule?

[sosukesuzuki]

@thorn0 hmm, I have no idea. I got it, such code may not be used much in the real world.

[alexander-akait]

Good idea

[fisker]

Why not keep the old one, add a new one?

[thorn0]

Because the old one was not real-life code. That's not how d3 is used. Our heuristics are developed to format real code. Ideally all the foo-bar-baz should be removed from that folder and replaced with more reasonable examples.

[fisker]

Realworld case of #7889 (comment)

array.flat().reverse()

Many methods on array can be called without arguments, .slice() to copy, .join() to join with ,, .sort(), .keys() / .entries() on last call. .shift() / .pop() get another type and then chain, objectsArray.pop().toString()

[thorn0]

@fisker In real code, the result of such array operations is usually used somehow, not discarded. E.g. result = array.flat().reverse();. Anyways, I've tweaked that part a bit, and now such simple chains without arguments aren't split even if they're expression statements. Please play with the playground to check how it works.

[travislwatson]

@thorn0 After I commented on #7884, I kept mulling over what a heuristic would be that made me not care about intentional line breaks, and after 2 days I think I've found it:

Never line-break inside a method chain before breaking the method chain itself.

I have extracted and hopefully simplified a few examples here.

First, line breaks inside an arrow function:

const Profile = view.with({ name }).as((props) => (
  <div>
    <h1>Hello, {props.name}</h1>
  </div>
))

// Better:
const Profile = view
  .with({ name })
  .as((props) => (
    <div>
      <h1>Hello, {props.name}</h1>
    </div>
  ))

Second, line breaks inside an object definition:

const fullName = RR.createQuery((o) => `${o.firstName} ${o.lastName}`).with({
  firstName,
  lastName,
})

// Better:
const fullName = RR
  .createQuery((o) => `${o.firstName} ${o.lastName}`)
  .with({ firstName, lastName })

Or most egregiously, line breaks inside an method call:

const [firstName, setFirstName] = RR.name('user.profile.firstName').createState(
  'John'
)

// Better
const [firstName, setFirstName] = RR
  .name('user.profile.firstName')
  .createState('John')

Hopefully this is a useful heuristic for this scenario.

[thorn0]

@traviswatsonws A very good point, thanks. As for your first example (with a function), it's unlikely we'll change how it's formatted because the current output is intended (#469 (review), #469 (review)), but the other two indeed can be improved as you wrote. Implementation-wise, it might be challenging, and not in this PR maybe, but I'll look into it. For your second example, we also need to accept and implement #8055 first.

[travislwatson]

@thorn0 Would this discussion be better had in a different issue?

As for the first function example, that case actually makes sense to me, and my example as provided is actually on the acceptable side, with the exception of indentation:

EDIT: I don't know enough about this indentation stuff, I probably shouldn't have even mentioned it, but I'm going to leave it here for posterity. Maybe just... skip over it ;-)

// This feels normal to not be indented
items.map(mapFunction).forEach((item) => {
  // ...
})

// This feels awkward to not be indented, especially because if we add just one more step...
const output = items.map(mapFunction).map((item) => {
  // ...
})

// Then we get this chain treatment, which is indented
const output = items
  .map(mapFunction)
  .map((item) => {
    // ...
  })
  .map(otherMapFunction)

Both are chains, just one more step, so the inconsistency feels "off".

All that said, if I'm hypothesizing, that "break inside the lambda" treatment feels quite unique, and has some constraints:

• There is only a single lambda in the chain
• The lambda argument is a top level argument; it's not inside an array or object definition
• The lambda argument is the last step of the chain (I think this is how it's behaving now, based on my testing)

And all this only matters when we are over the print width. I think these constraints are consistent with the link you provided.

Here is an example that feels awkward/confusing to me for the reasons above:

// Has 2 lambdas, and one of them is inside an object definition
const Profile = view.with({ name: (state) => state.name }).as((props) => (
  <div>
    <h1>Hello, {props.name}</h1>
  </div>
))

[thorn0]

The lambda argument is a top level argument; it's not inside an array or object definition
Here is an example that feels awkward/confusing to me for the reasons above:

@traviswatsonws Good catch. I'll fix this one in this PR. As for the rest, yes, we need to open a new issue.

[thorn0]

@traviswatsonws I've tried to implement your suggestion. Please play with this PR (playground) and tell me what you think. To install it locally, run npm install thorn0/prettier#tweak-method-chains

[travislwatson]

I like it @thorn0. It's not as verbose as what I had in my head, but playing around with different argument amounts and lengths feels pretty good.

👍

[thorn0]

It's not ready for merging yet. Committed it mostly to get feedback. I might move these last changes to another PR because they need refactoring and further tweaking.

E.g. there is this idempotence issue:

Prettier pr-8063
Playground link

--parser babel

Input:

export default function theFunction(action$, store) {
  return action$.ofType(THE_ACTION).switchMap(action => Observable
    .webSocket({ url: THE_URL,
      more: stuff(),
      evenMore: stuff({ value1: true, value2: false, value3: false }),
    })
    .filter(data => theFilter(data))
    .map(({ theType, ...data }) => theMap(theType, data))
    .retryWhen(errors => errors));
}

Output:

export default function theFunction(action$, store) {
  return action$.ofType(THE_ACTION).switchMap((action) =>
    Observable
      .webSocket({
        url: THE_URL,
        more: stuff(),
        evenMore: stuff({ value1: true, value2: false, value3: false }),
      })
      .filter((data) => theFilter(data))
      .map(({ theType, ...data }) => theMap(theType, data))
      .retryWhen((errors) => errors)
  );
}

Second Output:

export default function theFunction(action$, store) {
  return action$.ofType(THE_ACTION).switchMap((action) =>
    Observable.webSocket({
      url: THE_URL,
      more: stuff(),
      evenMore: stuff({ value1: true, value2: false, value3: false }),
    })
      .filter((data) => theFilter(data))
      .map(({ theType, ...data }) => theMap(theType, data))
      .retryWhen((errors) => errors)
  );
}

[thorn0]

I'm reverting these changes, moving them to a separate PR: #8063.

I've reverted the current PR to the stage where it was approved + a fix for a bug described in #7889 (comment). Let's merge this first.