Change:
expect(element.props).toEqual(expectation); }); <ins> it('should warn when `key` is being accessed', function() { spyOn(console, 'error'); var container = document.createElement('div'); var Child = React.createClass({ render: function() { return <div> {this.props.key} </div>; }, }); var Parent = React.createClass({ render: function() { return ( <div> <Child key="0" /> <Child key="1" /> <Child key="2" /> </div> ); }, }); expect(console.error.calls.length).toBe(0); ReactDOM.render(<Parent />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Child: `key` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)' ); }); it('should warn when `ref` is being accessed', function() { spyOn(console, 'error'); var container = document.createElement('div'); var Child = React.createClass({ render: function() { return <div> {this.props.ref} </div>; }, }); var Parent = React.createClass({ render: function() { return ( <div> <Child ref="childElement" /> </div> ); }, }); expect(console.error.calls.length).toBe(0); ReactDOM.render(<Parent />, container); expect(console.error.calls.length).toBe(1); expect(console.error.argsForCall[0][0]).toContain( 'Child: `ref` is not a prop. Trying to access it will result ' + 'in `undefined` being returned. If you need to access the same ' + 'value within the child component, you should pass it as a different ' + 'prop. (https://fb.me/react-special-props)' ); }); </ins> it('allows a string to be passed as the type', function() { var element = React.createFactory('div')(); expect(element.type).toBe('div');

Discussion:
The props and are reserved by React, and used internally. Component authors may attempt to access these properties (thinking they could read the value, as per ). We could use (in dev mode) to warn if or is accessed, and point the user to a note/discussion somewhere. That way, users who actually run into the issue will always get a timely message that sends them directly to the relevant explanation/discussion. This would be a good first bug, if we decide we actually want to do it.
This sounds like a great idea to me!
Yeah this seems reasonable.
hi, I am interested in working on this; as I am looking forward to contribute. Kindly show me the way. Thanks in advance!
Take a look at , that should give you a good start and a good idea of what we would be looking for.
Thanks Checking it out right away.
I have taken a look at the pull request, and associated code review comments. It seems the warn-once policy is required here, as implemented in I am not sure I fully understand how this module achieves this, so I am reading it now. As per the code review comments in , I am using the URLs instead of StackOverflow URLs. But the comments over there also mentioned that the PR might break some test cases. I am not sure about the edge cases here. I feel like I could use some help on understanding this. Instead of using GitHub issue comments, is it possible to use some chat-platform such as IRC or slack room or Gitter?
The module achieves deduplication by setting a boolean if it has already warned. The comments about breaking tests are referring to the failing unit tests. Just run and to verify that everything is working before pushing your changes. There are many places where you can discuss, including the IRC channel and/or reactiflux. There are also github issues (which is what our core team predominantly uses), as well as several other channels. The community is pretty big, but nothing is quite as good as reading through the code and github issues, IMHO.
Sorry, I was away. is ready to be reviewed.