# 6.5: External Props and Mapping Components

Frequently, props will be passed not directly from the parent to the child, but through an intermediate component. Props can be passed from ancestors to descendants through as many 'middleman' components as you need. Like with our discussion about information exchange between components on the last page, this is both a blessing and a curse. The benefit is that any component can draw upon methods or data from a component higher in the hierarchy, but the drawback is that it requires more props for this information to be passed.

Without building lots of components, we're going to simulate this grandparent-parent-child relationship being described. Let's add the below array of objects above the `export default PropsDemo extends React.Component{` line in our code. The object represents the props we want to share with our `FunctionalComp` component, and `PropsDemo` is now the parent middleman to get this information to `FunctionalComp`. You can think of the object we're adding as coming from a higher ancestor component in the React hierarchy, or as from outside the React project altogether. Either way, we have more links in the chain of information passage from source of data to component using that data.

```javascript
const propsFromOutside = [
    {string: 'Color Toggle', function: 'colorToggle'},
    {string: 'Background Color Toggle', function: 'backgroundColorToggle'},
    {string: 'Border Radius Toggle', function: 'borderRadiusToggle'},
    {string: 'Border Style Toggle', function: 'borderStyleToggle'}
]
```

Let's now change how prop values are defined inside the calls of each `FunctionalComp` instance within our render. We're going to move away from hard-coded values to using our array of objects to give us props values. This will feel a little wild, but we'll break down what's going on after you implement this code:

```javascript
<FunctionalComp string={propsFromOutside[0].string} function={this[`${propsFromOutside[0].function}`]}/>
<FunctionalComp string={propsFromOutside[1].string} function={this[`${propsFromOutside[1].function}`]}/>
<FunctionalComp string={propsFromOutside[2].string} function={this[`${propsFromOutside[2].function}`]}/>
<FunctionalComp string={propsFromOutside[3].string} function={this[`${propsFromOutside[3].function}`]}/>
```

As you can see, all of our prop values now refer to the `propsFromOutside` array instead of the values we manually typed out. Each of our `string` props refers to an index number of our propsFromOutside array, giving us back one of the four objects in our array. The .string grabs hold of the value of the string key inside each of the 4 objects.

More complex perhaps is how we refer to the value of each `function` prop. Each `function` prop first refers to `this`. We know the `this` keyword lets us refer to whatever outter conext our code currently resides in. For instance, our `FunctionalComp` calls occur within our `render()` method, which is contained within our `PropsDemo` class component. In this sense, the `render()` method contains our inner context, and the `PropsDemo` class is the outter context holding our `FunctionalComp` calls. So in this case, `this` refers to our class component `PropsDemo`.

Next, we see square brackets after our use of `this`. As a refresher, the square brackets let us grab hold of the key from an object by inserting a string. In this case, we use string interpolation `${...}` to refer to a variable string, whatever the `function` key is for each object. In essence, we can grab hold of any key our `propsFromOutside` array refers us to. Take a minute to check it out and begin to wrap your head around it before we streamline this code a bit.

One thing to begin to train your eye to look for is repeated code structure. When you see repeated code structure as you write, there's always a more elegant way to write out what you're doing. There are nuances to this statement, but we can begin to explore this topic by refactoring our `FunctionalComp` calls within our render method. Let's rebuild our calls as follows inside our render:

```javascript
render(){
  const display = propsFromOutside.map((el, index) => {
    return(
        <FunctionalComp key={index} string={el.string} function={this[`${el.function}`]}/>
    )
  })
  return(
    <div className="main">
        <div className="mainDiv">
            <div style={this.state}>
                {display}
            </div>
        </div>
    </div>
  )
}
```

Let's talk about what's going on here. We've outsourced the job of calling each `FunctionalComp` to the display array. The display array maps each object inside of `propsFromOutside` to a `FunctionalComp` call, storing the string and function from that object as props inside the `FunctionalComp`. Notice that we've added `key={index}` to our component calls. If you take that out of your .map, you'll getting the following warning in your console:

![Missing Key Error](https://373648234-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LAU8Yfynp7GOpkPwiVi%2F-LTTwGDdlYl2_jF5FgeU%2F-LTTwIgx5AAugjkRO68_%2F6.5-key-error.png?generation=1544559871937646\&alt=media)

Why does React care about a unique key for each call of `FunctionalComp`? Well, React is smart enough to 're-render' (re-display) to the page only the components which have changed props. So, for instance, if one of the `FunctionalComp` components has been referring to the `colorToggle` method, but it's now referring to the `borderStyleToggle` method, React will re-render that component, as the data tied to that component has changed. However, React won't be able to identify if props and internal information for a component has changed unless the component has some sort of name tied to it. Hence the use of `key`. By giving each component a `key`, React can now identify when a single instance of `FunctionalComp` has changed, and re-display just that component to the DOM, rather than re-rendering all of the `FunctionalComp` instances.

In our last view of props within this module, we're going to explore PropTypes.