11

I have seen two ways to destructure props in React.

    function MyComponent({name,age,height}){
            // do stuff here
    }

or

    function MyComponent(props){
            const {name,age,height} = props
            // do stuff here
    }

Suppose this component is used as

<MyComponent name="bob" age={25} height = {175} haspets={false}/>

Here is my questions:

If I used the first way of destructuring, does it mean that I will have no access to other props, in this case haspets

What are some pros/cons of these two ways?

Jasperan
  • 2,154
  • 1
  • 16
  • 40
Phantom
  • 423
  • 1
  • 5
  • 13
  • All you have to add is add that prop to the list `function MyComponent({name,age,height,haspets})` if you need to use it – Moinul Hossain Jan 04 '20 at 00:48
  • 2
    You can also do `function MyComponent({name,age,height,...others})`. In that case rest of the props (in your case `haspets` ) pass will be available in `others` as an object – Moinul Hossain Jan 04 '20 at 00:49
  • Thanks, I asked the question because I didn't want to do too much excessive destructuring – Phantom Jan 04 '20 at 00:50
  • This isn't a bad question, but since it's really a matter of preference and largely contextual it's not a great fit for StackOverflow. – coreyward Jan 04 '20 at 00:54

2 Answers2

8

You can have access on the other properties of your object later, throught the arguments object, though as also pointed out on the link the rest parameters should be prefered.

<MyComponent name="bob" age={25} height = {175} surname="test" haspets={false} />

function MyComponent({ name, age, height, ...rest }){
      // rest will be an object like { surname: 'test', haspets: false }
}

One of the differences I can think of, and I suppose the most important, is that on the second case, while you are destructing your props object, you are using const on declaration.

In that way, you can no longer change these values on your MyComponent, while on your first case you could easily modify them.

Michalis Garganourakis
  • 2,872
  • 1
  • 11
  • 24
  • I thought props can be modified by parent components who passed them down anyway. I don't think a component can modify it's own props though. – Phantom Jan 04 '20 at 01:28
  • It shouldn't be modified, but it can when there is nothing preventing it by doing so. You can take a look here https://codesandbox.io/s/stupefied-sky-h3768. I'm just pointing a differnce between those two approaches that you've listed on your question, while I find myself using both of them equally. – Michalis Garganourakis Jan 04 '20 at 01:44
  • ok I see, so it will be like a local variable. Hence won't cause rerender and will be reset to whatever value passed to it whenever a rerender happens – Phantom Jan 04 '20 at 01:53
2

If you destructure your props from the function parameters, you won't be able to access any other props later on**, so your assumption is correct. As far as performance and other pros/cons though, these forms are pretty much identical. I happen to like this way, because I like as few additional variable declarations in my files as possible. It can, be a pain with functions that require lots of props.

**Unless you use the spread operator and store them in a separate variable.

tobiasfried
  • 1,689
  • 8
  • 19
  • 2
    Technically since this hypothetical functional component is being defined with the `function` keyword you can access `arguments` within the function body. Props are passed in as the first argument, so `arguments[0]` contains all of your props, regardless of what you destructure in the parameters list. Useful in a pinch! – coreyward Jan 04 '20 at 00:57
  • Right, but this won't work with Arrow functions and I feel like is considered poor practice. – tobiasfried Jan 04 '20 at 01:06