Ancestors

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

Toot

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

Descendants

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