Real World Use Case for Renaming Destructed Properties
Tags: es6, quicktips
Published: 2019-06-05 15:54:03

---
title: Real World Use Case for Renaming Destructed Properties
published: true
description: 
tags: es6, quick tips
---

You hear about a new javascript feature, and how it will help you be more productive or write cleaner code. You're pumped. You go to the docs to figure out how to implement it and come across a `var foo = bar` example.

Then you google something like `real world example of ...`  or at least that is my usual workflow. 

### Assigning destructed variables to new variable names

I knew that you could assign new variable names to destructed objects. I read more about this feature on the [mozilla docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Assigning_to_new_variable_names) and looked over their `foo/bar` example:
```javascript
    var o = {p: 42, q: true};
    var {p: foo, q: bar} = o;
     
    console.log(foo); // 42 
    console.log(bar); // true
```
This all seemed easy to digest, but I still couldn't think of a real world use case. That was until I was working on a [Gatsby]() site and making multiple graphql queries for the page data.

### My real world use case for renaming destructed object properties

I had a page that had multiple queries for data, and had similar schemas. The queries looked like this:
```javascript
    export const query = graphql`
    	query {
        	imageFiles {
            	edges {
                	node {
                    	...
                    }
                }
            }
            sourceYaml {
            	edges {
                	node {
                    	...
                    }
                }
            }
        }
    `
```
I wanted to use both sets of data inside my page component, and as you can see both have similar shapes and the same property names. 

This query results in something like this:
```javascript
    data {
    	imageFiles {
        	edges {
            	node {
                	...
                }
            }
        }
        sourceYaml {
        	edges {
            	node {
                	...
                }
            }
        }
    }
```
 Then to use this data in my page component, I would pass it in as a prop like so:
```javascript
    const Page = ({ data }) => {
    	return (
    		... page html
        )
    }
```
This would work, but because I don't want to write out long prop drilling like `data.imageFiles.edges` a bunch of times I destructed the data object out to something like this
```javascript
    const Page = ({ 
    	data: {
        	imageFiles: { edges },
            sourceYaml: { edges },
    	} 
     }) => {
     	return (
        	... page html
        )
     }
```
Now this won't compile because  `edges` defined twice. After writing this out, and seeing that I would run into problems, I knew immediately that I could use the renaming feature here to solve this. 

Here is what the updated and renamed data object destructing looks like
```javascript
     const Page = ({ 
    	data: {
        	imageFiles: { edges: sourceImages },
            sourceYaml: { edges: sources },
    	} 
     }) => {
     	return (
        	... page html
        )
     }
```
Now inside this component, I can use `sourceImages` and `sources` which are assigned to the `edges` property of `imageFiles` and `sourceYaml`. 

Not only will this shorten the data prop, but I think it will also make it easier to read. So when myself or another developer come to this code in the future, seeing `sourceImages` and `sources` will make more sense than something like `data.imageFiles.edges`

Please leave any comments of how you have used this feature in the real world!