Emerging JavaScript pattern: multiple return values(loige.co)
loige.co
Emerging JavaScript pattern: multiple return values
https://loige.co/emerging-javascript-pattern-multiple-return-values
9 comments
Matlab has this!
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.
article mentions performance concerns only in the context of Array destructuring
Returning an object and returning an array aren't exactly new concepts in Javascript? The only relatively-new part is destructuring assignment, but that's been around since 2015, since it was added in ES6.
Right and the article is from 2018.
I have been using it for awhile.
I have been using it for awhile.
Sure, but I’ve been returning objects for 10+ years
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.
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.
Did we read the same article?
I do absolutely not see the author advocating returning values in an array instead of an object, in fact, they seems to be saying the exact opposite? (starting with the array example, and then going to the object example afterwards)
The primary point of the article is the destructuring which makes the syntax much nicer.
I do absolutely not see the author advocating returning values in an array instead of an object, in fact, they seems to be saying the exact opposite? (starting with the array example, and then going to the object example afterwards)
The primary point of the article is the destructuring which makes the syntax much nicer.
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:
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'];
Please some admin (or you, Loige) add the "[2018]" tag since this is well established in 2020. It was "emerging to already there" back in 2018.
I also missed generators from this list, which are the "official" (but a lot more complex than the ones showed here!) way of having multiple async returns:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I also missed generators from this list, which are the "official" (but a lot more complex than the ones showed here!) way of having multiple async returns:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
C# also supports this with the Tuple type
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
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.
I’ve found returning a tuple with my validation functions to be very helpful.
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.
let [isValid, err] = validate(data)
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.
[deleted]
You probably already know this but you can destructive just the second half as well.
`cont [, err] = validate(data)`
`cont [, err] = validate(data)`
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.
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.