Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emerging JavaScript pattern: multiple return values

loige.co

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Emerging JavaScript pattern: multiple return values

#11

Post by aurbano »

forest_dweller wrote: post #5

So instead of returning a object, we stuff two values into an array and this grants us the advantage of saving a few extra characters. This is pretty hacky and it smells. it also won't work in languages like typescript (without losing the advantage of using it) which is frequently used.

While the article does advocate for objects vs arrays for returning multiple values I wanted to address the second part of you comment.

It will work just fine in TypeScript, where you can define a "fixed size" array as a type:

    type Test = [number, string];
    const test: Test = [1, 'something'];
The second line will fail compilation if there's a different number of elements in that array, or if the types don't match.

Re: Emerging JavaScript pattern: multiple return values

#12

Post by rasz »

Kiro wrote: post #2

I don't understand what kind of stuff people build in React where performance implications of this sort is relevant. I'm building games where I loop through potentially thousands of objects 60 times a second and optimizations on that level still don't make any difference. It's always rendering that is the bottleneck. Shouldn't it be the same with React?

article mentions performance concerns only in the context of Array destructuring

Re: Emerging JavaScript pattern: multiple return values

#14

Post by Kiro »

joshribakoff wrote: post #7
Kiro wrote: post #2

I don't understand what kind of stuff people build in React where performance implications of this sort is relevant. I'm building games where I loop through potentially thousands of objects 60 times a second and optimizations on that level still don't make any difference. It's always rendering that is the bottleneck. Shouldn't it be the same with React?

No one said to do this for performance

I was referring to the Performance implications section.

Re: Emerging JavaScript pattern: multiple return values

#15

Post by paledot »

While there are isolated use cases for returning multiple values (quotient/remainder being a good example), all of the real-world cases I've seen where the author tried have been a serious code smell, a missed warning that the encapsulation was weak. Refactoring to use single return values or coherent value objects almost always produced cleaner, more readable, more testable code as a result.

Re: Emerging JavaScript pattern: multiple return values

#16

Post by tinkertamper »

I’ve found returning a tuple with my validation functions to be very helpful.

  let [isValid, err] = validate(data)
It’s nice for a few reasons:

1. I know anything returned `err` is safe to display back to the user

2. Using the array (as opposed to an object) can allow me to name the values when I destructure so it can be used multiple times in the same block with useful naming.

3. I can destructure just the first half `[isValid]` if that’s all I care about.

4. More generally it helps keep the code readable. Other control flows might rely on some casting, assumptions, or exceptions but this way presents a nice customizable api for users writing the code, and a readable api for those reviewing the code.

Re: Emerging JavaScript pattern: multiple return values

#17

Post by carterklein13 »

This is one of the main reasons I love using Go for backend work, and the lack of this functionality is just one of the reasons I dislike JavaScript.

Anything to make JS feel less haphazard and more elegant (i.e. using TypeScript) is awesome in my books. Looking forward to hopefully using this pattern in my personal work going forward, and maybe trying to introduce it to my team ta work.

Re: Emerging JavaScript pattern: multiple return values

#18

Post by [deleted] »

tinkertamper wrote: post #16

I’ve found returning a tuple with my validation functions to be very helpful. let [isValid, err] = validate(data) It’s nice for a few reasons: 1. I know anything returned `err` is safe to display back to the user 2. Using the array (as opposed to an object) can allow me to name the values when I destructure so it can be used multiple times in the same block with useful naming. 3. I can destructure just the first half…

[deleted]

Re: Emerging JavaScript pattern: multiple return values

#19

Post by noman-land »

tinkertamper wrote: post #16

I’ve found returning a tuple with my validation functions to be very helpful. let [isValid, err] = validate(data) It’s nice for a few reasons: 1. I know anything returned `err` is safe to display back to the user 2. Using the array (as opposed to an object) can allow me to name the values when I destructure so it can be used multiple times in the same block with useful naming. 3. I can destructure just the first half…

You probably already know this but you can destructive just the second half as well.

`cont [, err] = validate(data)`

Re: Emerging JavaScript pattern: multiple return values

#20

Post by AstroJetson »

carterklein13 wrote: post #17

This is one of the main reasons I love using Go for backend work, and the lack of this functionality is just one of the reasons I dislike JavaScript. Anything to make JS feel less haphazard and more elegant (i.e. using TypeScript) is awesome in my books. Looking forward to hopefully using this pattern in my personal work going forward, and maybe trying to introduce it to my team ta work.

Same reason I'm a Lua fan, multiple return values is a super function. With Lua it's baked into the language.
Post reply on HN