0

The title might not be the best way to describe the problem, but I was wondering if there was a better practice to declaring an object in getDefaultProps?

In my render method I call several keys from from a prop/state that get updated on a click event i.e. this.props.player.name. The problem is that on page load this.props.player is blank and calling .name errors out. I know I can do something like ...

getDefaultProps: function() { return { player: { name: null, team: null position: null } }; }

but it doesn't feel right. I was hoping there might be something similar to how Ruby does .try() where it won't try to call a method on a undefined prop.

Ryan Grush
  • 2,076
  • 3
  • 37
  • 64

3 Answers3

1

The problem is specifically that this.props.player is undefined, if you define an empty object it will prevent the error from occurring. It's not bad practice to stub out the keys you're anticipating, but setting the default value to {} will be enough to prevent it from throwing.

Carl Vitullo
  • 853
  • 6
  • 15
  • But getting this.props.player.name will throw you exactly "Uncaught TypeError: Cannot read property 'name' of undefined", no? – Michael Rasoahaingo Jun 03 '16 at 20:02
  • @MichaelRasoahaingo I thought so too but it does work for one level down. So when I declare `player: {}`, this returns with no error `this.props.player.name` but something like this `this.props.player.first_name` errors out. – Ryan Grush Jun 03 '16 at 20:14
  • Yep, it's throwing because you're trying to reference a property on `undefined`. If it's an object, trying to get properties that don't exist off an object is just `undefined`. – Carl Vitullo Jun 03 '16 at 20:45
0

You can create your data from ImmutableJS. Then you can get any part of your data like this:

this.state.getIn(['player', 'name', ...])

or 

this.state.get('player')

This will not throw error even player is not defined or other, it will return undefined (or null) I don't remember

The update and updateIn work the same

see the doc here

Michael Rasoahaingo
  • 1,069
  • 6
  • 11
  • If he's already using ImmutableJS sure, but this would be a bad reason to add ImmutableJS. – Carl Vitullo Jun 03 '16 at 19:51
  • Immutable or another lib is a part of all good practices of doing react, why not starting using it? – Michael Rasoahaingo Jun 03 '16 at 19:55
  • Using it to solve this problem is massive overkill. Adding a dependency you don't understand because it happens to solve a trivial problem with a simpler solution isn't good practice. – Carl Vitullo Jun 03 '16 at 19:56
  • It looks a good library I might add it at some point, but I agree with Carl in that its a bit overkill for this specific problem. Thanks for the tip though. – Ryan Grush Jun 03 '16 at 20:10
  • It's good when you're trying to optimize, it makes it much easier to implement `shouldComponentUpdate` if you can guarantee that your objects are immutable. I personally don't use it because it's possible to get those same guarantees just by using good practices in plain Javascript. – Carl Vitullo Jun 03 '16 at 20:48
0

I'd like to add this vanilla JS solution too - var x = (user || {}).name;

Source

Community
  • 1
  • 1
Ryan Grush
  • 2,076
  • 3
  • 37
  • 64