constuniqueItemsArray=['Apple','Banana','Orange','Banana','Apple'];// Adding new items to the ArrayuniqueItemsArray.push('Grapes');uniqueItemsArray.push('Orange');// Already exists but added again// Checking if a value exists in the ArrayconsthasGrapes=uniqueItemsArray.includes('Grapes');// Deleting an item from the ArrayuniqueItemsArray=uniqueItemsArray.filter(item=>item!=='Banana');uniqueItemsArray.forEach(item=>{console.log(item);});
✅ Use instead:
constuniqueItemsSet=newSet(['Apple','Banana','Orange','Banana','Apple']);// will show ['Apple', 'Banana', 'Orange']// Adding new unique items to the SetuniqueItemsSet.add('Grapes');uniqueItemsSet.add('Orange');// Checking if a value exists in the SetconsthasGrapes=uniqueItemsSet.has('Grapes');// Deleting an item from the SetuniqueItemsSet.delete('Banana');// Iterating through the Setfor (letitemofuniqueItemsSet){console.log(item);}
Are delayed transactional emails costing you user satisfaction? Postmark delivers your emails almost instantly, keeping your customers happy and connected.
This is a great list of suggestions! I definitely push for #1 in code reviews all the time.
I am on the fence about #2, though. There are times it's useful to pass a specific state rather than having to check to see if we need to toggle. It could be written to support an optional forced value, which would cover both possibilities.
const[isModalVisible,toggleModalVisibility]=useReducer((currentValue,newValue)=>newValue??!currentValue,false);// Regular toggletoggleModalVisibility();// Force a statetoggleModalVisibility(false);
I have been a software professional since I was in high school in 1998. I'm enthusiastic about open source, and I really enjoy working in unusual software systems or within strange constraints.
I wish you had explained the “why” here. As-is, this reads doctrinaire, especially since constructs like Set are only more efficient once you achieve a greater n size.
Out of curiosity, what's the benefit of going with useReducer over useState in #2?
Since we use lots of toggles, I've got it abstracted out to a custom hook that lets you either just toggle it (99% of the time) or force-set a value (a few rare instances):
You can make a custom hook too, I like the useReducer way because it's simple and easily readble. As @oculus42 said, you can give a custom value if you want
const[isModalVisible,toggleModalVisibility]=useReducer((currentValue,newValue)=>newValue??!currentValue,false);// Regular toggletoggleModalVisibility();// Force a statetoggleModalVisibility(false);
I'm a software developer currently working on multiple projects at Kellton Tech. Mostly doing TypeScript and React on a daily basis, focusing on front-end work. On a side note I also work with Clojure
Valuable tips, the first time I saw it I identified myself lol, I'm going to apply it to reduce my gigantic ifs. Thank you very much for sharing your knowledge 🦤.
I am an enthusiastic professional, having rich experience in Product Development with Microsoft technologies.Skilled in C#, .Net core, Web Api, microservices, Azure and AWS to build distributed system
Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.
Top comments (16)
This is a great list of suggestions! I definitely push for #1 in code reviews all the time.
I am on the fence about #2, though. There are times it's useful to pass a specific state rather than having to check to see if we need to toggle. It could be written to support an optional forced value, which would cover both possibilities.
Woah -- how had I not learned about the nullish coalescing operator
??
until today 😯I think I could sub it in for most of my
||
s and it would be more syntactically accurate.Yeah! Pretty good suggestion thank's! :)
Regarding #4 - Efficient Object Cloning
It's good to know that the spread variant won't work as expected:
That is because spreading will only do a shallow copy, but keep it's references to deep objects.
Example:
So in that case, the structuredClone is better to use.
I wish you had explained the “why” here. As-is, this reads doctrinaire, especially since constructs like
Set
are only more efficient once you achieve a greatern
size.Strongly agree on #1 and #3!
Out of curiosity, what's the benefit of going with
useReducer
overuseState
in #2?Since we use lots of toggles, I've got it abstracted out to a custom hook that lets you either just toggle it (99% of the time) or force-set a value (a few rare instances):
You can make a custom hook too, I like the useReducer way because it's simple and easily readble. As @oculus42 said, you can give a custom value if you want
The second option: why is that better?
Hi @bop! It more simple and readable :)
Good very nice
Very nice 👍
Valuable tips, the first time I saw it I identified myself lol, I'm going to apply it to reduce my gigantic ifs. Thank you very much for sharing your knowledge 🦤.
<3
Very cool
Nice article.
Thank you !!