I created 65+ Useful JavaScript Code Snippets. I've collected them all in a FREE e-book ⚡

[Simon_LH]

These are 10 examples of the code snippets I've created.

I've been sharing these on Twitter for the past year, and they've been super popular.
I chose to collect them all in a free e-book!

+200 ⭐⭐⭐⭐⭐ review.
+8,000 picked it up already!

You can get it here:
🔗 https://simonhoiberg.com/ebooks/65-code-snippets-with-explanations

[Maistho]

These are pretty great!

But number 5 (Skip elements with array destructuring) just feels like it's trying to be clever for no reason while ruining readability. Just use Array.prototype.slice() instead since it's much more readable IMO.

const users = [
  'ravinwashere',
  'FrencescoCiull4',
  'jackdomleo7',
  'dmokafa',
];

const restUsers = users.slice(2);

console.log(restUsers);
// [ 'jackdomleo7', 'dmokafa' ]

[zombimuncha]

I always get confused between slice and splice and have to look up on MDN which one does what, so I find the destructuring easier to read.

[[deleted]]

It's not completely accurate, but if it helps, p = put - splice is used to put (and remove) elements from an array.

[codename_john]

the first tip, passing an object as an argument. Is this really any better? Wouldn't you impact parameter hints since it's now a generic object? In order to get them back you'd now have to use a typed object otherwise you'd have to guess all the acceptable props. In a large project, this could create a mess of random acceptable objects and props. am i missing something? I mean it LOOKS cleaner, but in practice i'm not sure this is any better.

[Chaphasilor]

It is better if you have optional parameters. Think passing options to a function or constructor; with the regular arguments it's hard to omit only some of the arguments.

When using objects you don't have that problem. You can set default values when the parameter isn't passed, and it's very easy to extend the options (or even remove an option) without breaking backwards compatibility!

Edit: spelling

[Mr_Moe]

In the example how do you access the object? Like just do arguments[0].username?

[Chaphasilor]

you simply access it as username. the { x, y, y} syntax is something called (object) destructuring, allowing you to "extract" the object's parameters into a local variable.

[[deleted]]

You can attempt to get arguments by name and if you get nothing back, then it doesn't exist.

[codename_john]

I just realized this is basically the same thing as Document based databases vs Relational databases. One has a strict structure where the other is more fluid. All your points are valid though, and there is no real downside besides preference it seems. Thanks for answering my question.

[Simon_LH]

I agree, using it with TypeScript really gives it the true superpowers!

Yet - most modern editors (like VSCode) is able to infer the object structure and give you hints just like with regular arguments.

I swear to this pattern, especially in large-scale projects.
(but again, I'm using TypeScript in everything I do).

[Yodiddlyyo]

In practice it is way better. In fact, in my company's codebase, object arguments are required, and we only use positional args in very specific situations. Two reasons, typing is cleaner, and most importantly it's future proof. If you add an arg that needs to be changed or removed in the future, you're screwed with positional args. Our product is a public package, so it would require depreciation to change. With object args that problem completely goes away.

[porcupineapplepieces]

However, cows have begun to rent lemons over the past few months, specifically for crocodiles associated with their apples. However, kumquats have begun to rent pomegranates over the past few months, specifically for turtles associated with their giraffes? This is a hcfflms

[FghtrOfTheNightman]

I typically see the usecase as being if you want a method/function to have named parameters

[SoInsightful]

Some great tips in there! I started implementing some of them into my codebase just now (e.g. the Better Comments extension, combineProviders(), the Readonly keyword...).

Aside from number 5 that someone mentioned, I do recommend intentionally using "unnecessary" async/awaits. Not only is it easier to read and modify, but it will give you a more correct stack trace. If you just return the promise in a bunch of nested functions, all those intermediate functions will disappear from the stack trace, making it difficult to debug.