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 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.
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 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
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 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:
Pretty cool! It makes switch a functionnal expression as a ternary operator. And the syntax is pretty crystal clear
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!
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.
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
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.
Dart now has a switch expression with modern pattern matching. I really like it.
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.
actually looks cool
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
ts-pattern is nice too! But I used IIF's like this all the time too
ts-pattern is the way
I prefer nested ternaries. They are not hard to read if formatted properly with line breaks and indents.
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;
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 🤮