Categories
JavaScript Best Practices

JavaScript Best Practices- Parsing Numbers, Promises, Unicode and Regex

Spread the love

JavaScript is a very forgiving language. It’s easy to write code that runs but has mistakes in it.

In this article, we’ll look at ways to parse number better, requiring await in async functions, and adding a Unicode flag to our regex.

Add a Radix Argument When Calling parseInt

The JavaScript parseInt function takes a 2nd argument that has the radix of the number being parsed. The radix is the 0x prefix of the number.

Before ES5, parsseInt autodetected octal literals, which makes anything with a 0 before it is parsed as an octal number instead of a decimal number.

However, ES5 or later changed this behavior and now numbers with a leading 0 are parsed as a decimal number.

But it’s still a good idea to explicitly specify the parseInt function so that everyone knows what kind of number do we want to parse the number string to.

For instance, instead of writing the following code:

const num = parseInt("021");

We should write the following code:

const num = parseInt("021", 10);

The 10 in the 2nd argument makes sure that parseInt parses '021' as a decimal number so that it or any developer won’t be confused with what it’s parsed as.

Therefore num is 21.

We can also specify that it’s parsed as an octal literal as follows:

const num = parseInt("021", 8);

Then num is 17 since octal 021 is 17 as a decimal number.

No async Functions Which Have No await Expression

In JavaScript, an async function is one that has a chain of promises inside and only returns a promise.

An async function without any await expressions in it just return a promise with whatever we put after the return statement or a promise that resolves to undefined if we didn’t return anything inside.

There’s no point in having async functions that have no await expressions inside since we either aren’t running any promise code inside it or that we forgot the await before the promise so that they won’t be chained properly.

Either way, we should rectify these situations. If it’s just synchronous code, then we don’t need to put them inside an async function.

If we forgot to resolve the promises with await , then we should put await in front of the promises.

Therefore, we shouldn’t have code like:

const foo = async () => {  
  return 'foo';  
}

Instead, we write something like:

const getMichael = async () => {  
  const response = await fetch('https://api.agify.io/?name=michael');  
  const data = await response.json();  
  return data;  
}

The code above is an async function to call an API, which is a common use of promises.

In the end, it returns the data that’s obtained from the API.

If we throw an error, in an async function as follows:

const error = async () => {  
  throw new Error("error");  
}

We can replace the code above with:

const error = () => Promise.reject(new Error("error"))

They both return promises which are rejected with an Error instance.

Use of u flag on Regex

With the u flag added to the end of our regex, we can properly parse UTF-16 characters, which includes characters like emojis and other characters in an extended character set.

It also makes syntax errors be thrown so that we’ll know about them. Without the u flag, syntax errors won’t be thrown if we have them in our regex.

Therefore, it lets is find errors early on instead of when we’re running code that’s after the regex is defined.

So, instead of writing code like the following:

const a = /foo/;  
const b = new RegExp('foo');

We should write the following:

const a = /foo/u;  
const b = new RegExp('foo', 'u');

Conclusion

The radix argument should be added when we call parseInt so that it’ll always be parsed in as the kind of number that we want.

It also eliminates any ambiguity when it comes to what kind of number is returned from parseInt .

Async functions that have no await expressions in it probably don’t need to be inside an async function.

The u flag should be added after a regex literal or object so that we can see syntax errors with our regex earlier and also checks for characters in the UTF-16 character set properly.

By John Au-Yeung

Web developer specializing in React, Vue, and front end development.

Leave a Reply

Your email address will not be published. Required fields are marked *