The Talent500 Blog

11 Simple Tips For Writing Better JavaScript Component Code

HarVar

Newbie coders rarely take the road less travelled. The destination is reached, but the journey forward is necessarily fatiguing. Sounds unfamiliar? Hang on. Often, what you have with beginners is quickly-produced working code, but not quality code. Instead of terse, flexible components, you have clunky blocks that make for very little scalability. Amateurs tend to have a ‘this is temporary, we’ll fix it later’ kind of attitude, which doesn’t hold well in the higher realms of coding where, to quote Robert C. Martin, ‘clean code reads like well-written prose’. 

However, delivering efficient components on deadline is as difficult as writing poetry on demand. You want your component to be as reusable as a Lego block, as shareable as a secret, as light as a feather, and as simple as simple can get. But what you land up with is a component that’s born lean and grows clunky – with several ‘bug-fixes’ tacked onto it at every end – and lands up being unusable in just a short while. To avoid such a scenario, which can be costly in many senses, it’s a smart idea to backtrack a bit and line up your tactics against best practices that experienced coders abide by.

Here are 11 tips for writing better JavaScript components you can implement going forward.

Keep it short and simple (KISS)

When Eric Elliot publicly took to Twitter to get views on ‘what people think the biggest/most common mistake software developers make is?’, Brendan Eich, co-founder of the Mozilla Foundation, favorited 2 views: “not being pragmatic, overcomplicating things” and “underestimating their talent”.

The KISS principle is a good antidote to over complication as it pertains both to brevity (short) and logic (simple). In practical terms, once you’ve got your first draft down, start asking questions like:

With an eye on optimisation, you’ll soon be writing code that’s performant and light.

Make use of destructuring

The destructuring syntax is great for making your code shorter, and more readable too. It works with arrays and objects, allowing you to unpack values and properties and bind them to variables. And what’s even better is that you can extract a whole bunch of variables with a single statement, which means that it’s a very practical way of making complex functions uncomplicated. You can use the destructuring syntax with nested arrays/ objects as well.

Avoid functions with side effects

Pure functions give you the same output if given the same input, always. They have zero side effects (mutations). To take your functional programming game up a notch, make it a practice to always use pure functions when you can. It’ll help you create components that are scalable and reusable, yes, but also free from bugs crawling about a shared mutable (e)state.

Don’t repeat yourself

Stick to the DRY principle, as coined by Andy Hunt and Dave Thomas in The Pragmatic Programmer. It’ll help keep your codebase cleaner and your components reusable. Maintainability, testing, and costs are also at stake here and having unnecessary code scattered about the place makes it that much harder to keep your software free of bugs. To start ‘DRYing’ up your code, look for patterns and repetition and then, replace that with abstractions. Rinse, repeat, DRY.

Prefer functional components

If you’re ever at the ‘functional vs class’-component crossroad, stop. Can a functional component do the job? If yes, use one. Functional components are plain, old, ‘dumb’, clean, and simple. No boilerplate, no lifecycles, no states—just less code and chock full of JavaScript best practices. What’s there to not love about them?

Limit lines, characters, and indentation

Extremely long code doesn’t necessarily display erudite coding skills. In fact, it is better to write in smaller chunks, so that you (or someone else!) can go back to your code in search for a nugget of logic anytime later and not be lost searching for a needle in a haystack. Some believe 500 lines is a limit you shouldn’t trespass. Others would say less. But the idea is that you keep your components maintainable. The same goes for: 

Name variables and components smartly

You want to go about naming based on content and not context, because you want your code to be easily used in other contexts too. In terms of functions, think about what job it is doing. Next, a good practice is to start with a verb, because a verb is how you get a job done. So, generatePlaylist is a good name. For components, it is better to be more generic. Playlist would be better than AudioPlaylist or VideoPlaylist, which could make the component seem restricted in its functionality. 

Learn when to use async/ await

You’ll find a ton of guides online advocating the use of async-await, but before you sync with the trend, wait a bit and think if over-generalisation makes for any good in the long run. Rather than be polarised, look at async-await and promises as tools you can use to make your code more potent. And the only question is which one to use. On Medium you can find quite a comprehensive set of rules, which are worth checking out.

Aim for one component, one function

In the world of components, small and function-specific is reusable. Also, if your component is working with generality, you have a better chance of sharing it with other teams. And smaller components are easier to test and maintain too. Large components can work, but you’d probably be trading off reusability, testability, shareability and the joy of having less code!

Skip commenting and code more clearly

Some coders believe that including a lot of comments is like the old saying, “empty vessels make the most noise”. See this quote from an article on Towards Data Science:

“In general, comments are a wart that stipulates poor design, especially long-winded comments where it’s clear the developer didn’t have a clue what the heck they are doing and tried to make up for it by writing a comment.” – Sabesan Sathananthan

But CodeinWP is a bit more technical with their evaluation. They say commenting can:

Try vanilla JavaScript!

It’s good to make your favourite coding flavour vanilla, because frameworks can come and go (and indeed they do) but understanding the language behind the libraries is bound to pay richer dividends. Vanilla JavaScript is powerful, and in case you are building components for multiple UI frameworks and libraries, going framework-agnostic, at least to a level, may be the best and only way for you to keep your code maintainable and free from duplication.  

To these 11 best practices, you can add several others like:

But to really grow as a JavaScript software engineer, it’s necessary to get hands on real-world experience, and rub shoulders with professionals who know of a ton of more tips and nuances, all learnt by way of experience. 

You’d be able to find some of the best talent at Fortune500 companies, and to make your way there, sign up with Talent500 and undergo a skill-based assessment. Our platform will then match your profile to premium jobs at top tech companies, giving you a chance to claim your spot in an elite group of engineers!

0