I wrote my first few lines of JavaScript not long after the language was invented. If you told me at the time that I would one day be writing a series of articles about elegant patterns in JavaScript, I would have laughed you out of the room. I thought of JavaScript as a strange little language that barely even qualified as “real programming.”
\nWell, a lot has changed in the 20 years since then. I now see in JavaScript what Douglas Crockford saw when he wrote JavaScript: The Good Parts: “An outstanding, dynamic programming language … with enormous, expressive power.”
\nSo, without further ado, here is a wonderful little pattern I’ve been using in my code lately. I hope you come to enjoy it as much as I have.
\nPlease note : I’m pretty sure I did not invent any of this. Chances are I came across it in other people’s code and eventually adopted it myself.
\nMost of my functions now accept a single parameter of type object and many of them return or resolve to a value of type object as well.
Thanks in part to the destructuring feature introduced in ES2015, I’ve found this to be a powerful pattern. I’ve even given it the silly name, “RORO” because… branding? 🤷♂️
\nNote: Destructuring is one of my favorite features of modern JavaScript. We’re going to be taking advantage of it quite a bit throughout this article, so if you’re not familiar with it, here’s a quick video to get you up to speed.
\nyoutube: https://youtu.be/-vR3a11Wzt0\nThe inimitable Beau Carnes explains ES2015 Destructuring syntax in about 6 minutes.
Here are some reasons why you’ll love this pattern:
\nLet’s look at each one.
\nSuppose we have a function that returns a list of Users in a given Role and suppose we need to provide an option for including each User’s Contact Info and another option for including Inactive Users, traditionally we might write:
\nfunction findUsersByRole (\n role,\n withContactInfo,\n includeInactive\n) {...}A call to this function might then look like:
\nfindUsersByRole(\n 'admin',\n true,\n true\n)Notice how ambiguous those last two parameters are. What does “true, true” refer to?
\nWhat happens if our app almost never needs Contact Info but almost always needs Inactive Users? We have to contend with that middle parameter all the time, even though it’s not really relevant (more on that later).
\nIn short, this traditional approach leaves us with potentially ambiguous, noisy code that’s harder to understand and trickier to write.
\nLet’s see what happens when we receive a single object instead:
\nfunction findUsersByRole ({\n role,\n withContactInfo,\n includeInactive\n}) {...}Notice our function looks almost identical except that we’ve put braces around our parameters. This indicates that instead of receiving three distinct parameters, our function now expects a single object with properties named role, withContactInfo, and includeInactive.
This works because of a JavaScript feature introduced in ES2015 called Destructuring.
\nNow we can call our function like this:
\nfindUsersByRole({\n role: 'admin',\n withContactInfo: true,\n includeInactive: true\n})This is far less ambiguous and a lot easier to read and understand. Plus, omitting or re-ordering our parameters is no longer an issue since they are now the named properties of an object.
\nFor example, this works:
\nfindUsersByRole({\n withContactInfo: true,\n role: 'admin',\n includeInactive: true\n})And so does this:
\nfindUsersByRole({\n role: 'admin',\n includeInactive: true\n})This also makes it possible to add new parameters without breaking old code.
\nOne important note here is that if we want all the parameters to be optional, in other words, if the following is a valid call…
\nfindUsersByRole()… we need to set a default value for our parameter object, like so:
\nfunction findUsersByRole ({\n role,\n withContactInfo,\n includeInactive\n} = {}) {...}An added benefit of using destructuring for our parameter object is that it promotes immutability. When we destructure the object on its way into our function we assign the object’s properties to new variables. Changing the value of those variables will not alter the original object.
Consider the following:
\nconst options = {\n role: 'Admin',\n includeInactive: true\n}\n\nfindUsersByRole(options)\n\nfunction findUsersByRole ({\n role,\n withContactInfo,\n includeInactive\n} = {}) {\n role = role.toLowerCase()\n console.log(role) // 'admin'\n ...\n}\n\nconsole.log(options.role) // 'Admin'Even though we change the value of role the value of options.role remains unchanged.
It’s worth noting that destructuring makes a_ shallow _copy so if any of the properties of our parameter object are of a complex type (e.g. array or object) changing them would indeed affect the original.
With ES2015 JavaScript functions gained the ability to define default parameters. In fact, we recently used a default parameter when we added ={} to the parameter object on our findUsersByRole function above.
With traditional default parameters, our findUsersByRole function might look like this.
function findUsersByRole (\n role,\n withContactInfo = true,\n includeInactive\n) {...}If we want to set includeInactive to true we have to explicitly pass undefined as the value for withContactInfo to preserve the default, like this:
findUsersByRole(\n 'Admin',\n undefined,\n true\n)How hideous is that?
\nCompare it to using a parameter object like so:
\nfunction findUsersByRole ({\n role,\n withContactInfo = true,\n includeInactive\n} = {}) {...}Now we can write…
\nfindUsersByRole({\n role: ‘Admin’,\n includeInactive: true\n})… and our default value for withContactInfo is preserved.
How often have you written something like this?
\nfunction findUsersByRole ({\n role,\n withContactInfo,\n includeInactive\n} = {}) {\n if (role == null) {\n throw Error(...)\n }\n ...\n}Note: We use double equals (==) above to test for both null and undefined with a single statement.
What if I told you that you could use default parameters to validate required parameters instead?
\nFirst, we need to define a requiredParam() function that throws an Error.
Like this:
\nfunction requiredParam (param) {\n const requiredParamError = new Error(\n `Required parameter, \"${param}\" is missing.`\n )\n\n // preserve original stack trace\n if (typeof Error.captureStackTrace === ‘function’) {\n Error.captureStackTrace(\n requiredParamError,\n requiredParam\n )\n }\n\n throw requiredParamError\n}Now, we can set an invocation of requiredParam as the default value for role, like so:
function findUsersByRole ({\n role = requiredParam('role'),\n withContactInfo,\n includeInactive\n} = {}) {...}With the above code, if anyone calls findUsersByRole without supplying a role they will get an Error that says Required parameter, “role” is missing.
Technically, we can use this technique with regular default parameters as well; we don’t necessarily need an object. But this trick was too useful not to mention.
\nJavaScript functions can only return a single value. If that value is an object it can contain a lot more information.
Consider a function that saves a User to a database. When that function returns an object it can provide a lot of information to the caller.
For example, a common pattern is to “upsert” or “merge” data in a save function. Which means, we insert rows into a database table (if they do not already exist) or update them (if they do exist).
\nIn such cases, it would be handy to know wether the operation performed by our Save function was an INSERT or an UPDATE. It would also be good to get an accurate representation of exactly what was stored in the database, and it would be good to know the status of the operation; did it succeed, is it pending as part of a larger transaction, did it timeout?
When returning an object, it’s easy to communicate all of this info at once.
\nSomething like:
\nasync saveUser({\n upsert = true,\n transaction,\n ...userInfo\n}) {\n // save to the DB\n return {\n operation, // e.g 'INSERT'\n status, // e.g. 'Success'\n saved: userInfo\n }\n}Technically, the above returns a Promise that resolves to an object but you get the idea.
\n\n“Function composition is the process of combining two or more functions to produce a new function. Composing functions together is like snapping together a series of pipes for our data to flow through.” — Eric Elliott
\n
We can compose functions together using a pipe function that looks something like this:
function pipe(...fns) {\n return param => fns.reduce(\n (result, fn) => fn(result),\n param\n )\n}The above function takes a list of functions and returns a function that can apply the list from left to right, starting with a given parameter and then passing the result of each function in the list to the next function in the list.
\nDon’t worry if you’re confused, there’s an example below that should clear things up.
\nOne limitation of this approach is that each function in the list must only receive a single parameter. Luckily, when we RORO that’s not a problem!
\nHere’s an example where we have a saveUser function that pipes a userInfo object through 3 separate functions that validate, normalize, and persist the user information in sequence.
function saveUser(userInfo) {\n return pipe(\n validate,\n normalize,\n persist\n )(userInfo)\n}We can use a rest parameter in our validate, normalize, and persist functions to destructure only the values that each function needs and still pass everything back to the caller.
Here’s a bit of code to give you the gist of it:
\nfunction validate(\n id,\n firstName,\n lastName,\n email = requiredParam(),\n username = requiredParam(),\n pass = requiredParam(),\n address,\n ...rest\n) {\n // do some validation\n return {\n id,\n firstName,\n lastName,\n email,\n username,\n pass,\n address,\n ...rest\n }\n}\n\nfunction normalize(\n email,\n username,\n ...rest\n) {\n // do some normalizing\n return {\n email,\n username,\n ...rest\n }\n}\n\nasync function persist({\n upsert = true,\n ...info\n}) {\n // save userInfo to the DB\n return {\n operation,\n status,\n saved: info\n }\n}I said at the outset, most of my functions receive an object and many of them return an object too.
\nLike any pattern, RORO should be seen as just another tool in our tool box. We use it in places where it adds value by making a list of parameters more clear and flexible and by making a return value more expressive.
\nIf you’re writing a function that will only ever need to receive a single parameter, then receiving an object is overkill. Likewise, if you’re writing a function that can communicate a clear and intuitive response to the caller by returning a simple value, there is no need to return an object.
An example where I almost never RORO is assertion functions. Suppose we have a function isPositiveInteger that checks wether or not a given parameter is a positive integer, such a function likely wouldn’t benefit from RORO at all.