Are these JavaScript tricks acceptable in production code?

Other Questions JavaScript
1

Hey everyone! I’ve been thinking about some JavaScript quirks I use in my code. Want to know if you do the same or have any cool tricks up your sleeve?

Here are a few I’m guilty of using:

  1. Checking if an array is empty with !(arr + []) instead of Array.isArray()
  2. Using obj.list ||= [] to set an empty array when obj.list is falsy
  3. Running a function like func && func() to execute only if it exists
  4. Comparing with var === !0 for a strict boolean true check

I’m especially tempted to use #2 like this:

const { info } = fetchData()
info.items ||= []
info.items.map((item) => doSomething(item))

Instead of the longer version:

const { info } = fetchData()
if (Array.isArray(info.items)) {
  info.items.map((item) => doSomething(item))
}

What do you think? Any other sneaky JS tricks you use in your projects?

2

nah mate, those tricks are too fancy for prod. keep it simple, yeah? i’ve seen devs lose their minds tryna debug that kinda stuff. stick to the basics - makes life easier for everyone. plus, some of those tricks might not work on older browsers. just my 2 cents tho

3

While those JavaScript tricks might seem clever, I’d caution against using them in production code. Readability and maintainability should be prioritized over brevity. The Array.isArray() check is more explicit and self-documenting. For setting default values, consider using the nullish coalescing operator (??) instead. As for function execution, a simple if statement is often clearer. These ‘tricks’ can make code harder to understand for other developers or even yourself months later. In my experience, sticking to more conventional patterns leads to fewer bugs and easier collaboration in the long run. It’s tempting to use shortcuts, but clarity should be the goal in professional environments.

4

I’ve been down that road before, using clever tricks to shorten my code. While it’s fun to play with these JavaScript quirks, I’ve learned the hard way that they can backfire in production.

One time, I used similar shorthand in a large project. Months later, when we needed to debug an issue, it took us ages to decipher what was happening. My teammates were frustrated, and I felt pretty embarrassed.

Now, I stick to more straightforward approaches. It might seem verbose at first, but it pays off in the long run. Code readability and maintainability are crucial, especially when working in a team or on long-term projects.

That said, I do think it’s valuable to understand these tricks. They can come in handy for quick scripts or personal projects. Just be cautious about using them in production code where others might need to maintain it.