DEV Community

Cover image for Write More Robust JavaScript: 7 Best Practices

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 ...
Collapse
 
supunkavinda profile image
Supun Kavinda • Edited
  1. 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
}
Collapse
 
metcoder profile image
Carlos Fuentes

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.

Collapse
 
vyckes profile image
Kevin Pennekamp

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.

Collapse
 
jsmanifest profile image
jsmanifest

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

Collapse
 
brunomguimaraes profile image
Bruno Guimarães

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

Collapse
 
jsmanifest profile image
jsmanifest • 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'))
Enter fullscreen mode Exit fullscreen mode

or

const mikeTheFrog = createFrog('mike')
const williamTheChildFrogOfMike = createFrog('william')
mikeTheFrog.addChild(williamTheChildFrogOfMike)
Enter fullscreen mode Exit fullscreen mode
Collapse
 
raghavmisra profile image
Raghav Misra

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!

Collapse
 
jsmanifest profile image
jsmanifest

Your welcome!

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

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.

Collapse
 
jsmanifest profile image
jsmanifest • 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.

Collapse
 
metalmikester profile image
Michel Renaud

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