Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
I would take a similar route though I'd use false as the switch argument. Remember switch statements are if(x === y ) as opposed to if(x == y ) so we can't use truthy/falsey.
In order to make it work, I'd have a simple truthy to bool converter function. It takes up a bit of space but I think it's very readable.
consttoBool=a=>!!a;constvalidateInput=({field1,field2,field3})=>{switch(false){// if anything failscasetoBool(field1):returnPromise.reject('Missing field1');caseArray.isArray(field2):returnPromise.reject('field2 is not an array');casetoBool(isValidType(field3)):// this may not need toBoolreturnPromise.reject('field3 is invalid');default:// If nothing fails resolve.returnPromise.resolve();}}
@joelnet
Why shouldn't you use switch(true){case binaryexp: return stuff}? It's the same control flow as if(){} else if(){} else if(){} or if you are always returning if() return; if() return; if() return. What could go wrong? Fallthrough?
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
Yeah, Result<Err, Val> is an awesome datatype, but it's not the norm in JS, unfortunately.
How great would Promise<Err, Val> = Future<Result<Err, Val>> be :)
Instead, they integrated with exceptions, which makes throwing inside an async function great, but makes awaiting a fallible promise pretty ugly.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
That's the difficulty is going opposite of the norm. It really works out well when your entire application is designed that way, but can be odd when you inject it into an existing application.
Consistency across the application is more important. So I will do these things with a new app, but code in the same style as existing apps just for consistency.
Cofounded Host Collective (DiscountASP.net). Cofounded Player Axis (Social Gaming). Computer Scientist and Technology Evangelist with 20+ years of experience with JavaScript!
You shouldn't, but you can 😉
I don't think I've written a single switch statement since I left the Javaland, so nothing to worry about.
I wanted to suggest that way too but am on mobile 😁
Why shouldn't you?
And now I'm at a PC
I would take a similar route though I'd use
false
as the switch argument. Remember switch statements areif(x === y )
as opposed toif(x == y )
so we can't use truthy/falsey.In order to make it work, I'd have a simple truthy to bool converter function. It takes up a bit of space but I think it's very readable.
You could also replace your custom
toBool
function with the built-inBoolean
constructor.Oh wow, I honestly didn't know that existed. It looks like it does the exact same thing as
!!
so would be a great replacement.@skaterdad @link2twenty the
Boolean
function not theBoolean
constructor. The difference is important becauseAnd not even
Boolean(new Boolean(''))
will save you.You'd have to go full
(new Boolean('')).valueOf()
to learn the truth.(As opposed to
String(new String(true))
andNumber(new Number('2'))
which do manage to extract the primitive value.)I leave you with this:
Bet you won't guess the result of the last two without evaluating :v
@joelnet Why shouldn't you use
switch(true){case binaryexp: return stuff}
? It's the same control flow asif(){} else if(){} else if(){}
or if you are always returningif() return; if() return; if() return
. What could go wrong? Fallthrough?When given multiple ways to write something, I always prefer writing an expression over statements.
So I wouldn't use a
switch
or anif
when I could use aternary
I bet you're all about those throw expressions, aren't you? ;)
Hmm. Well, I have used function expressions to throw, so this would be an improvement.
But since we're on the subject of Exception, I'll use this opportunity to rant about Exceptions.
Unless your intent is to halt the program, an Exception should not be thrown.
If your function can result in an exception, return it. This would follow a similar pattern as Promises.
And also similar to a callback:
Example:
The benefits are:
Yeah,
Result<Err, Val>
is an awesome datatype, but it's not the norm in JS, unfortunately.How great would
Promise<Err, Val> = Future<Result<Err, Val>>
be :)Instead, they integrated with exceptions, which makes
throw
ing inside anasync
function great, but makesawait
ing a fallible promise pretty ugly.That's the difficulty is going opposite of the norm. It really works out well when your entire application is designed that way, but can be odd when you inject it into an existing application.
Consistency across the application is more important. So I will do these things with a new app, but code in the same style as existing apps just for consistency.
Look what I found.
This guy knows what up ;)