Add in-methods-params rule

nLight commented 7 years ago

That rule allows one to forbid usage of destructuring in methods params.

We've had the following situation and decided to forbid usage of destructuring in methods params completely, while still allowing it for higher order functions

The following example demonstrates rather extreme case, but it is very easy to get there by adding one field at a time.

Why is it bad?

It can become very messy especially in a combination of max chars rule
no opportunity to give a name to the param, which is especially bad in a class context because interface is unclear in this case

Solution

Forbid it completely
Do destructuring in the method body on the first line

class Test {
  loadSomeDataFromServer(
    {
      url,
      anotherParam,
      oneMore,
      someFlag
    }
  ) {
    // function body goes here
  }
}

PS. eslint was yelling at me so I fixed indentation as well.

lukeapage commented 7 years ago

Looks good. I think I would have gone for an option on in-params but I'm OK with this. Will merge and do package upgrades later today.

nLight commented 7 years ago

Hey, thanks for the rapid feedback! I'm happy to discuss extending the in-params rule. Gotta find good option name maybe?

nLight commented 7 years ago

I dropped linting changes

lukeapage commented 7 years ago

published as 2.1.0

nLight commented 7 years ago

\o/ Thank you very much!

lukeapage / eslint-plugin-destructuring

Add in-methods-params rule #40