Functional Conditions: If one is using Typescript, the should also define the array with "as const" at the end. This will add the benefit of having it as a tuple type and and beeing able to derive all valid keys from it. ( just a suggestion) Async/Await Trap: I would consider using "Promise.allSettled" instead of "Promise.all". Reason is that "allSettled" makes it easier to handle errors, in case of "all" we would need a try/catch block for that. Encaspulation: I would rather use a class in this case, but thats a subjective choice. Oh but a really good video!
The JS-Feature allowing this to work is called 'closures' btw, if you don't already know about it. It allows returned functions to remember the context that they were created in, so that they can still access information after the parent function, that returned them, has been executed and Popped off the callstack of the JS-Engine.
For the first example, I also sometimes use a helper function to handle the if logic: function isCombiningMark(codePoint) { return (codePoint >= 0x0300 && codePoint = 0x1AB0 && codePoint = 0x1DC0 && codePoint = 0x20D0 && codePoint = 0xFE00 && codePoint
If it’s a big data set sure. Although for something as simple is this it will be negligible. It might even end up being very slightly slower just because of the cost of creating the set.
Great video! I really love and need these types of videos. I'm doing self-teaching through The Odin Project and without a mentor or someone checking on me it can be easy to develop bad practices / habits. Thank you! Would like to see more of these videos. Subscribed.
the idiomatic style should be used by default unless for some reason you have to loop over 10 000 000 elements, then a for/while loop should be used to get the best performance lol
I'm coming from a .Net background, so I'm wondering why use function instead of class to contain? The part about being functional is an area I need to work on.
although the class way is more optimal if you're planning to create millions of counters, because the increment & decrement methods only exist as single copies in memory, whereas the function way creates those two functions in memory for each counter instance.
The demonstrated function is a factory function which differs in some important ways from classes. Usually classes are the way to go especially for more substantial programs. The advantage to using such a factory function (although the one in the video is not functional - pun intended), is that it gives you more flexibility and less dependencies, as factories simply return a complete object with a new copy of each and every method and property name when called. Factories also facilitate the use of execution context (this), as it will always refer to the same object. You can also modify the methods and properties of the newly created object without much concern for dependencies (breaking other objects). Of course, factories come with disadvantages too. They simply don't scale well, as tgey create copies of everything, they take quite a toll on memory. They are also a pain in the ass when debugging in a larger program, as they don't belong to a "type"/class. So if you want to know what function created the object, it will be very tedious to find it. Furthermore they usually don't use inheritance (imagine the trouble of debugging that mess) although it is technically possible with Object.create. But yea, usually classes are the way to go.
For the first example, why not to use switch/case statements, if we assume all options are going to be a single ASCII character values, handling the options should be in a constant time.
The constant time thing doesn't matter at all. There's no reasonable way where this would scale to the point of any real difference in speed between solutions. Maybe there would be in some hyper-optimization heavy environment, but if that was the case you wouldn't be using JavaScript lol. As for using a switch/case here, you could but I don't think that really makes it more readable personally. It's also less scalable, because if we needed to add some other unrelated condition, we couldn't do that very easily with switch (e.g. something like y != null && [...].includes(x) would be very complicated with switch).
I ran into this at work. I optimized my function using a set checking with .has() . Then I decided to verify it was actually faster. I tested the set, .includes, and just a regular object. .includes outperformed them all. I realized that under the hood there is probably some magic going on. And the size of the array impacts it- for small arrays just use .includes()
Your 1st example is prone to error if you really consider options being longer strings and x is a shorter string but not exactly equal. What you could do is keep the array of options but use .some() method and check with === And yes your code works here because the options are only 1 char length but since you choose options as variable name i dont find it semantically so far off the values of options possibly be longer
It would work fine in this case. Array includes() checks that the values are the same, it doesn't just look to see that they start the same. For example: ['abc'].includes('a'); // false ['abc'].includes('abc'); // true
You can use a set if you want, but given the array is so small it won’t really make any difference. If anything the set might be slightly slower just due to the construction cost. As for a switch, personally I don’t love that. For example, what if there was another condition added down the line along with this includes? It’s easy to do with the functional approach, but not so much with the switch. It also feels like a misuse of the language construct imo as we aren’t switching between cases.
5:33 Where i work at I always try to convince people that this is the way to code in javascript. However they refuse to do so simply because they don't understand nor want to understand what filter, map or find are in javascript.
Functional Conditions:
If one is using Typescript, the should also define the array with "as const" at the end. This will add the benefit of having it as a tuple type and and beeing able to derive all valid keys from it. ( just a suggestion)
Async/Await Trap:
I would consider using "Promise.allSettled" instead of "Promise.all". Reason is that "allSettled" makes it easier to handle errors, in case of "all" we would need a try/catch block for that.
Encaspulation:
I would rather use a class in this case, but thats a subjective choice.
Oh but a really good video!
wow this video is amazing and very helpful. I've been programming for 2 years and can't believe how much better your code is, it's so easy to read
The last example was mind-blowing
The JS-Feature allowing this to work is called 'closures' btw, if you don't already know about it.
It allows returned functions to remember the context that they were created in, so that they can still access information after the parent function, that returned them, has been executed and Popped off the callstack of the JS-Engine.
The last one was just a class with extra steps.
You forgot to return the count value in the encapsulation example
Oops, yeah that's probably something you would want lol 😅
Probably even better to return a getter function for the count value.
You are my favourite youtuber! Thank you for your amazing videos
Thanks, glad you enjoy them!
For the first example, I also sometimes use a helper function to handle the if logic:
function isCombiningMark(codePoint) {
return (codePoint >= 0x0300 && codePoint = 0x1AB0 && codePoint = 0x1DC0 && codePoint = 0x20D0 && codePoint = 0xFE00 && codePoint
Very good example of how code reviews should be
in the first one u can use a Set to speed up checkings (helpful when dealing with tons of data)
If it’s a big data set sure. Although for something as simple is this it will be negligible. It might even end up being very slightly slower just because of the cost of creating the set.
Great video! I really love and need these types of videos.
I'm doing self-teaching through The Odin Project and without a mentor or someone checking on me it can be easy to develop bad practices / habits.
Thank you! Would like to see more of these videos. Subscribed.
the idiomatic style should be used by default unless for some reason you have to loop over 10 000 000 elements, then a for/while loop should be used to get the best performance lol
Great video. Chadfrontend approves ✅
I'm coming from a .Net background, so I'm wondering why use function instead of class to contain?
The part about being functional is an area I need to work on.
the function way requires less code to define, and doesn't require writing "new Counter()", but rather "counter()" instead.
although the class way is more optimal if you're planning to create millions of counters, because the increment & decrement methods only exist as single copies in memory, whereas the function way creates those two functions in memory for each counter instance.
The demonstrated function is a factory function which differs in some important ways from classes. Usually classes are the way to go especially for more substantial programs. The advantage to using such a factory function (although the one in the video is not functional - pun intended), is that it gives you more flexibility and less dependencies, as factories simply return a complete object with a new copy of each and every method and property name when called. Factories also facilitate the use of execution context (this), as it will always refer to the same object. You can also modify the methods and properties of the newly created object without much concern for dependencies (breaking other objects).
Of course, factories come with disadvantages too. They simply don't scale well, as tgey create copies of everything, they take quite a toll on memory. They are also a pain in the ass when debugging in a larger program, as they don't belong to a "type"/class. So if you want to know what function created the object, it will be very tedious to find it. Furthermore they usually don't use inheritance (imagine the trouble of debugging that mess) although it is technically possible with Object.create.
But yea, usually classes are the way to go.
For the first example, why not to use switch/case statements, if we assume all options are going to be a single ASCII character values, handling the options should be in a constant time.
The constant time thing doesn't matter at all. There's no reasonable way where this would scale to the point of any real difference in speed between solutions. Maybe there would be in some hyper-optimization heavy environment, but if that was the case you wouldn't be using JavaScript lol.
As for using a switch/case here, you could but I don't think that really makes it more readable personally. It's also less scalable, because if we needed to add some other unrelated condition, we couldn't do that very easily with switch (e.g. something like y != null && [...].includes(x) would be very complicated with switch).
I ran into this at work. I optimized my function using a set checking with .has() . Then I decided to verify it was actually faster. I tested the set, .includes, and just a regular object. .includes outperformed them all.
I realized that under the hood there is probably some magic going on. And the size of the array impacts it- for small arrays just use .includes()
Your 1st example is prone to error if you really consider options being longer strings and x is a shorter string but not exactly equal. What you could do is keep the array of options but use .some() method and check with ===
And yes your code works here because the options are only 1 char length but since you choose options as variable name i dont find it semantically so far off the values of options possibly be longer
It would work fine in this case. Array includes() checks that the values are the same, it doesn't just look to see that they start the same.
For example:
['abc'].includes('a'); // false
['abc'].includes('abc'); // true
@@ConnerArdman I feel dumb, you are right
@@ConnerArdman I thought about String.includes not Array.includes, my bad
i feel calm now after i watched this video, bcs i never use for loop instead i use, map filter ETC, and i thought i was doing something so bad...
These are the very codes everyone say beautiful
You'll know if someone is a pro coder. On how elegant they validate Zip Codes.
1:46.. Instead of Array, why not use a Set or a switch case with fall-through?
You can use a set if you want, but given the array is so small it won’t really make any difference. If anything the set might be slightly slower just due to the construction cost.
As for a switch, personally I don’t love that. For example, what if there was another condition added down the line along with this includes? It’s easy to do with the functional approach, but not so much with the switch. It also feels like a misuse of the language construct imo as we aren’t switching between cases.
7:55 😭😭 don't manually write every function.
(I don't remember exact keys) Use ctrl+shift+downArrow to duplicate to bottom line
You sound like someone who should learn vim
5:33 Where i work at I always try to convince people that this is the way to code in javascript. However they refuse to do so simply because they don't understand nor want to understand what filter, map or find are in javascript.
Where do you work? You need to find a new job
@@nan5715Hahahahaha, I did already rage quit, they did not care much about the quality of the code, they just wanted to make it how they knew best
1:40 what about making it object?
You can, but I'm not sure I really see what the point would be to doing that.
Thanks a bunch, this was super insightful. Subscribed!
hey sup ?
Let's act like kids: IAM first wow😮😮😮😮😮🎉
Wooooooooo