DEV Community

Write More Robust JavaScript: 7 Best Practices

jsmanifest on January 20, 2020

Find me on medium 1. Use factory functions If you don’t know what a factory function is, it’s simply a function (that isn’t a class or ...

Read full post

Supun Kavinda • Jan 20 '20 • Edited

Always consider using try/catch when using JSON.parse or JSON.stringify

I normally use a function with try/catch inside it so that I don't need to always add try/catch blocks.

export function decodeJSON() {
   // JSON.parse() with try/catch
}
export function encodeJSON() {
   // JSON.stringify() with try/catch
}

Carlos Fuentes • Feb 5 '20

Hey! What good tips! Just a few comments about

Add methods on the .prototype when writing constructors

Even I'm not a huge fan of the class syntax sugar and the use of closures to simulate OOP, I think it is better to go for the class one to attach to one standard and keep it clean instead of keeping modifying the prototype.

Keep functions as simple as possible

No more than 60 lines
The function should do one and just ONE thing.
Try to return something as possible (avoid void functions)
Don't overuse currying and/or function composition
Last but not least, don't over DRY

Always consider using try/catch when using JSON.parse or JSON.stringify

Here depends a lot of your app structure, It is better if you don't use try/catch every time you use it but let the error goes bubbled up until you're able to handle it properly and show a message to the user or print it to the logs.

Kevin Pennekamp • Jan 20 '20

These are actually good tips! I am a big fan of the factory functions myself and prefer them over classes. Good to see that one coming by for once. And I even learned something. I never knew why you would want to put functions on the .prototype, but your explanation makes sense. Definitely gonna revise some of my packages with factory functions.

jsmanifest • Jan 20 '20

I am so glad to hear that! I was hoping I would grab some readers who were stuck on that prototype mystery!

Bruno Guimarães • Jan 20 '20

Great article, just one thing. Isn't the first snippet supposed to be addChild(name) ?

jsmanifest • Jan 20 '20 • Edited

Thank you! The intention of addChild's frog argument was that if the frog were to have children then it should have be instantiated with createFrog right before being passed in the instance. So there's the parent frog who had a baby (and the baby frog should have been instantiated with createFrog which is now also an instance of a frog sometime in our app before being passed as a child)

So in the code it would look something like this:

const mikeTheFrog = createFrog('mike')
mikeTheFrog.addChild(createFrog('william'))

const mikeTheFrog = createFrog('mike')
const williamTheChildFrogOfMike = createFrog('william')
mikeTheFrog.addChild(williamTheChildFrogOfMike)

Raghav Misra • Jan 20 '20

Great summary! I would like to think that I'm perfect in all of these 7 practices, but I really need to start writing tests. I'll be sure to check out the link you provided. Thanks!

jsmanifest • Jan 20 '20

Your welcome!

Adam Crockett 🌀 • Jan 20 '20

Why type is not a switch I don't know, although I have never heard that this is a conversation. Nor that using prototype when a class keyword is more appropriate.

jsmanifest • Jan 20 '20 • Edited

A switch here would be just fine since it just returns the result. However in a lot of situations when i'm considering switch cases I don't have to return the value evaluated from the case block which ultimately I'd become forced to put in a break which unnecessarily adds more lines than needed. In those situations it looks much nicer to just write if/else conditions while keeping the code short.

Michel Renaud • Jan 21 '20

I didn't know about (2). I'll definitely keep that one in mind. Thanks for sharing!