ES6 Spread Operator

One of the frustrations of being a ServiceNow developer is the fact that you don’t get to use all of the latest Javascript bells and whistles because the Rhino engine simple doesn’t support them.

It would be less of an issue if I was happy to live completely inside of the ServiceNow ecosystem, but I have things that I want to build outside of ServiceNow, so I’m faced with having to mentally switch back and forth from ‘old’ JavaScript to ‘new’ JavaScript.

One of the things that I’m trying to remember to use more often outside of my ServiceNow projects is the ES6 Spread Operator. I recently had a use case where the spread operator was perfect:

I was building an express route that was creating a new record in the many side of a one-to-many relationship, and since I had authentication in place that confirmed that the user was who they said they were, I didn’t want to make the user pass in their user id so that I could tie the new entry to the user (the ‘one’ side of the one-to-many relationship).

— Without Spread Operator —
// Create a new item
router.post(‘/items’,auth,async(req,res)=>{
    const item=new Item({
        name: req.body.name,
       description: req.body.description,
       weight: req.body.weight,
        owner:req.user._id
    })
    try{
        await item.save();
        res.status(201).send(item);
    }catch(error) {
        res.status(400).send(error);
    }
})

—

— With Spread Operator —

// Create a new item
router.post(‘/items’,auth,async(req,res)=>{
    const item=new Item({
        …req.body,
        owner:req.user._id
    })
    try{
        await item.save();
        res.status(201).send(item);
    }catch(error) {
        res.status(400).send(error);
    }
})

 

Without the spread operator, I have to manually assign each of the request body items that I want to be placed into the object that is ultimately saved as a new record or document in the database.

With the spread operator, I can just tell the system to break the request body into its component parts and then place those parts into my new object.

Using the spread operator is obviously less typing than the alternative. That isn’t a massive deal when it comes to a request that only has 3 key-value pairs, but could become a big deal on a much larger request.

More importantly, though is the fact that using the spread operator future proofs your code much better than the alternative. If I were to go back and add something to my items table, and the corresponding requests coming into my route, the spread operator will just grab that new data seamlessly and start saving it to the database. I don’t have to remember to come back and modify that route to allow for the inclusion of that new data.

You could have a problem with the spread operator resulting in user input that you weren’t expecting being saved into your database, so you’ll want to do some testing if you’re using the spread operator on something that is user input.

In my case, I confirmed that Mongoose is trimming off anything that isn’t established as part of my model for the collection, which means that the spread operator was the perfect solution for this problem.

 

 

Leave a Reply