Ancestors

Toot

Written by Nick Tune on 2024-11-02 at 13:34

After 7 months of using TypeScript, I'm still not a fan of parameter destructuring.

When digging through a codebase it's just feels like more noise that takes effort to mentally process and understand.

=> More informations about this toot | More toots from nick_tune@hachyderm.io

Descendants

Written by Nick Tune on 2024-11-02 at 13:38

I want to understand the signature of a function - what it takes and what it returns.

And parameter destructuring obscures that.

=> More informations about this toot | More toots from nick_tune@hachyderm.io

Written by Jason Parker (he/they) on 2024-11-02 at 13:35

@nick_tune That's when you do like the below, right? It feels so unnatural. I avoid it at all costs.

const { foo, bar, bar } = someObject

=> More informations about this toot | More toots from north@ꩰ.com

Written by Nick Tune on 2024-11-02 at 13:37

@north That's normal destructuring.

Parameter destructuring is when you do that directly in the parameter list:

=> More informations about this toot | More toots from nick_tune@hachyderm.io

Written by Alex Bird on 2024-11-02 at 17:38

@nick_tune That's interesting -- I also want our function signatures to be easy to read, but I haven't found parameter destructuring impacts that. Whether a function has (for example) three parameters or one destructured object parameter, I would read the signature more or less the same.

Can you tell me more about how they obscure? Or how you read them differently?

A lot of this hinges on what happens in our brain when we read code, which is pretty subjective. I'm asking for your opinion ✌🏻

=> More informations about this toot | More toots from alexanderbird@mstdn.ca

Written by Alex Bird on 2024-11-02 at 17:39

@nick_tune In case it helps the discussion, three examples:

assemblePizza1(base: Base, sauce: Sauce, toppings: Topping[]): Pizza;

assemblePizza2(base: Base, { sauce, toppings }: { sauce: Sauce, toppings: Topping[] }): Pizza;

assemblePizza3({ base, sauce, toppings }: { base: Base, sauce: Sauce, toppings: Topping[] }): Pizza

(although for 2 and 3 I would probably either extract a named type for the parameters, or move the destructuring inside the method depending on how related are the params)

=> More informations about this toot | More toots from alexanderbird@mstdn.ca

Written by Alex Bird on 2024-11-02 at 17:41

@nick_tune Am I right in thinking that you would advocate for either

assemblePizza1(base: Base, sauce: Sauce, toppings: Topping[]): Pizza;

or

assemblePizza4(parameters: { base: Base, sauce: Sauce, toppings: Topping[] }): Pizza;

rather than assemblePizza2 or assemblePizza3?

=> More informations about this toot | More toots from alexanderbird@mstdn.ca

Written by Alex Bird on 2024-11-02 at 17:42

@nick_tune For me, I think I would (currently) be more likely to opt for assemblePizza1 or

interface PizzaParameters {

base: Base;

sauce: Sauce;

toppings: Topping[];

}

assemblePizza5({ base, sauce, toppings }: PizzaParameters): Pizza;

(Although maybe I'll change my preference after hearing your view)

=> More informations about this toot | More toots from alexanderbird@mstdn.ca

Written by Nick Tune on 2024-11-02 at 17:49

@alexanderbird Yeah like this:

function printUserDetails({

name: { firstName, lastName },

address: { city, zipCode },

job: { title, salary }

}: {

name: { firstName: string; lastName: string };

address: { city: string; zipCode: number };

job: { title: string; salary: number };

}) {

=> More informations about this toot | More toots from nick_tune@hachyderm.io

Written by Alex Bird on 2024-11-02 at 18:01

@nick_tune Agh! The nesting‼ Yes if I was modifying that code I would probably change it like this:

interface Name { firstName: string; lastName: string ]

interface Address { city: string; zipCode: number }

interface Job { title: string; salary: number }

interface UserDetails { name: Name; address: Address; job: Job; }

function printUserDetails({ name, address, job}: UserDetails) {

const { firstName, lastName } = name;

const { city, zipCode } = address;

const { title, salary } = job;

=> More informations about this toot | More toots from alexanderbird@mstdn.ca

Written by Nick Tune on 2024-11-02 at 18:02

@alexanderbird I could live with that.

=> More informations about this toot | More toots from nick_tune@hachyderm.io

Written by Kaladin 🧑‍🦽💨 on 2024-11-02 at 16:37

@nick_tune amen. i had one team who had a lint rule that no function could have more than three parameters, but then required you destructure your extracted interface. It was a colossal waste of effort and delegated coherence from the compiler to the linter, which kept crashing under the weight of the rules. The only job I've ever left voluntarily after less than 2 years.

=> More informations about this toot | More toots from windrunner@toot.community

Written by Kamil Jędrzejuk on 2024-11-03 at 16:55

@nick_tune I get it—parameter destructuring in #TypeScript can add extra cognitive load. It’s meant to streamline code, but sometimes it just feels like more mental overhead instead of clarity

=> More informations about this toot | More toots from camil@mastodon.cloud