As much as I wish this was the answer to JS's missing pattern matching, I think this is too clever. The syntax is difficult to understand, especially for beginners, and it still has all the fragility of a traditional switch statement, including fall through if you forget a return and no exhaustiveness guarantee.
Even though I don't write vanilla JS on any projects now, I do this all the time in TS. I find this behaviour particularly useful in cases where I have to do a conditional assignment or initialisation. The benefit here is that the LSP will infer the variable as having a union type of all the return values rather than having a very broad type like number or string and that gives you a lot more of that sweet, sweet autocomplete. I also use IIFE initialisation for throwaway functions that I don't have any reuse scope for. One more advantage of this pattern is the need to declare fewer scoped variables whenever you need to transform the data from an external source: api, dom, fs, db, etc. into a more palatable form that the application can consume.
I think it depends. Declarative code is great and JS/TS needs this as a feature, but the extra syntax required for this trick may make the code harder to read, depending on the surrounding code. I'd say use it, but sparingly.
I think wrapping with a function and giving a coherent name, then invoking the function separately is the way I would go instead of the IIFE. If the code is in a hot path too, not having the overhead of creating a function every time could actually be significant
I think there's a mix. I see why people say it's clever and don't want to use it, but I also can see how this can kill nested if else issues. If you can make a case for it on the team, everyone can understand it, and it's testable? Don't see the issue.
As much as I wish this was the answer to JS's missing pattern matching, I think this is too clever. The syntax is difficult to understand, especially for beginners, and it still has all the fragility of a traditional switch statement, including fall through if you forget a return and no exhaustiveness guarantee.
I really love IIFE's, but imagine a new intern joins your team and the code is full of these. Pretty sure they would die 😆
Switch is a pretty basic functionality
I wish javascript had everything-expressions (switch, if, just everything)
if: ternary
Me: Can we have pattern matching?
Mom: We have pattern matching at home.
Pattern matching at home:
Even though I don't write vanilla JS on any projects now, I do this all the time in TS.
I find this behaviour particularly useful in cases where I have to do a conditional assignment or initialisation. The benefit here is that the LSP will infer the variable as having a union type of all the return values rather than having a very broad type like number or string and that gives you a lot more of that sweet, sweet autocomplete.
I also use IIFE initialisation for throwaway functions that I don't have any reuse scope for.
One more advantage of this pattern is the need to declare fewer scoped variables whenever you need to transform the data from an external source: api, dom, fs, db, etc. into a more palatable form that the application can consume.
This is great, thanks for sharing!
Pretty cool! It makes switch a functionnal expression as a ternary operator. And the syntax is pretty crystal clear
I think it depends. Declarative code is great and JS/TS needs this as a feature, but the extra syntax required for this trick may make the code harder to read, depending on the surrounding code. I'd say use it, but sparingly.
Since it’s a closure, I believe that function would be allocated on the heap every single time it runs. Gotta love javascript’s memory model.
I think wrapping with a function and giving a coherent name, then invoking the function separately is the way I would go instead of the IIFE. If the code is in a hot path too, not having the overhead of creating a function every time could actually be significant
I prefer nested ternaries. They are not hard to read if formatted properly with line breaks and indents.
for something really small, yes (i use it often). but for other stuff, better to just make a function and call it
I agree. The function's name by it self would improve the readabiity and it could be reused
I think there's a mix. I see why people say it's clever and don't want to use it, but I also can see how this can kill nested if else issues. If you can make a case for it on the team, everyone can understand it, and it's testable? Don't see the issue.
Dart now has a switch expression with modern pattern matching. I really like it.
ts-pattern is nice too! But I used IIF's like this all the time too
I prefer to just use an object and return a dynamic property.
...
const priorities = {...}
const p = priorities[job.priority] ?? defaultPriority
...
The range situation it'd not fit. But I also prefer to use an object 'cause it's hashed in JS;
actually looks cool
ts-pattern is the way
How about just making if statement an expression like some other programming languages did years ago? 😂
BTW, Java 17 has switch expressions
Can Java 17 run in the browser?
@@invinciblemode wasm.. duh!!
@@deadlyecho for making UI? No thanks lmao
@@invinciblemode well you can still write your lovely UI in HTML and Tailwind and handle events in Java or even Rust... 😉
@@deadlyecho disgusting 🤮