DEV Community

Cover image for A different way of handling required arguments in javascript functions
Enmanuel Durán
Enmanuel Durán

Posted on • Originally published at enmascript.com

A different way of handling required arguments in javascript functions

Originally posted on Enmascript.com

#Did you know is a new series of Enmascript where we write short and concise explanations about topics we consider might be relevant or underestimated, if you are looking for more complete in-depth articles check out our other series.

Usually in javascript if you want to validate required arguments, you would do something similar to this:

function Person(water, food, candy) {
    if (!water || !food) {
        throw new Error('water and food are required for Person');
    }

    // Do something with water and food...
}

The constructor Person Above would throw an error if no water or food is supplied, this is a relatively common and popular way of validating parameters, but there is a different more functional way to achieve this.

Create a helper function that throws an error:

const required = name => {
    throw new Error(`Parameter ${name} is required`);
};

In the case above we are passing an argument name to the function because it feels more natural to print the name of the parameter that is required.

Then we use it like this:

function Person(
    water = required('water'),
    food = required('food'),
    candy
) {
    // Do something with water and food
}

What is happening here? How does this validation work? It is very straight forward:

If we don't pass the required parameter's values, the required function is executed throwing an error and forcing the user to pass each mandatory value everytime the function is invoked.

Passing the name of the parameter to the required function is only a preference; we can decide not to pass it and make the helper function simpler, it is a personal choice.

This approach is not limited to this implementation, we can use this same principle to create our own argument's validators and reuse in our functions to enforce consistency and security.

Do you have ideas that are similar or related to this topic? share them with us.

Oldest comments (4)

Collapse
 
barendb profile image
Barend Bootha

Nice article, some thoughts form the sidelines.

My approach to this is to use something like Joi or Yup to validate the input. Our teams also follow a convention that if you have more than 3 arguments to make it an object.

The other reason to use something like Joi or Yup is you can have more finite control of what's passed in, so instead of having validation statements to check if a persons page is between 0-120 for example you can define that in a schema.

Thirdly if you use TypeScript this the required check is a non-issue. The compiler will validate that for you.

Collapse
 
vonheikemen profile image
Heiker

I feel like this would be better as a Babel plugin. It looks cool but i wouldn't want that runtime validation in production.

Collapse
 
itjusthitme profile image
Donald W Norman

Emmanuel,
Thank you for the tips. I'm just starting to code, but not so new to understand what a time saver this can be over a career writing code. I'm going to copy your article to keep around till I've got a good grasp of how to use it.

Collapse
 
sebbdk profile image
Sebastian Vargr • Edited

Cool, never thought much about using functions as default arguments apart from use with callbacks.

I could see my self using this trick with object destructured arguments as well to increase verbosity.