jiebi/CodeConvo huggingface dataset:
Code change:
Calling on in a component being Shallow Rendered will result in the error being thrown. I set up a test case:
Who would be best to answer this one?
Seems like a valid bug report — thanks and the test case is rad. I may not be able to look at this for a while, unfortunately.
no worries let me know if you need any more info from me. This was on React 14 beta btw (not sure if that matters)
I have the same issue. A simpler example that throws the error:
Any way of getting around this issue? I am currently running into it.
Sorry about the slow response from us (FB) here. I'm the principal author of the shallow render feature, but React core isn't my main gig and I've been swamped with product work. I don't have an offhand answer for you, but I've just put time on my calendar to look into this next week. Jim, Ben, Paul — if by chance one of you happened to take care of this before then, I wouldn't be mad :)
An update on my end. I think that my problem actually went away when I deduped my npm dependencies to remove an extra react version that was causing issues. If this error pops up again I'll let you know. Thanks for the response! On Fri, Aug 28, 2015, 9:38 PM Scott Feeney wrote:
Hmm I am still able to reproduce this issue in my test case after running npm dedupe
Just to clarify, my previous comment wasn't supposed to mean that the issue has gone away. I think I was seeing a separate issue caused by multiple react versions that I misidentified as this issue (I hope that makes sense).
I am getting this error, too. I'm using react v0.14.0-rc1. Looking at the code : Apparently .
Note that shallow rendered components override to return a instead of whatever it normally returns. That still shouldn't be undefined and should have a attribute, though.
I'm experiencing this issue too - your suggestion gets me past the initial error & on to in
Pretty sure this breaks many other things outside of , but I noticed moving to be directly above in fixed this for me.
We are also affected by this issue. I think shallow rendering is a really cool feature for testing, but unfortunately I can't use it for some of our components due to this bug.
I created pull request with a fix that works for me. Can someone else verify?
Any workaround for this issue?
:+1: Having same issue
Just ran into this too :/
Any update on this? I see that 0.14.3 was released, but these kind of tests are still failing.
I think I have to add a test to my pull request before it can be merged, but I did not get around to do it yet.
Closing in favor of which should merge soon.

Related discussion:
text: expect(result.props.className).toEqual('clicked'); }); <ins> it('can setState in componentWillMount when shallow rendering', function() { var SimpleComponent = React.createClass({ componentWillMount() { this.setState({groovy: 'doovy'}); }, render() { return <div>{this.state.groovy}</div>; }, }); var shallowRenderer = ReactTestUtils.createRenderer(); var result = shallowRenderer.render(<SimpleComponent />); expect(result).toEqual(<div>doovy</div>); }); </ins> it('can pass context when shallowly rendering', function() { var SimpleComponent = React.createClass({ contextTypes: {
Code change:
I'm trying to use the attribute as described here: Unfortunately, sometimes returns , when is called multiple times. MWE:
This is intended – when the component is unmounted or the ref changes, the old ref gets called with null before it's called with the new value (or the same component instance again). If you store the instance on your component, this effect should be unobservable as long as your component is mounted, but it prevents memory leaks. If you want to do something with in the ref handler, you should check if it's null.
Thanks for the information! I think this might be worth mentioning in the docs.

Related discussion:
text: 1. Assign a `ref` attribute to anything returned from `render` such as: <del> ```html <input ref="myInput" /> ``` </del> <ins> ```html <input ref="myInput" /> ``` </ins> 2. In some other code (typically event handler code), access the **backing instance** via `this.refs` as in: <del> ```javascript this.refs.myInput ``` </del> <ins> ```javascript this.refs.myInput ``` </ins> You can access the component's DOM node directly by calling `React.findDOMNode(this.refs.myInput)`.
Code change:
I'm trying to use the attribute as described here: Unfortunately, sometimes returns , when is called multiple times. MWE:
This is intended – when the component is unmounted or the ref changes, the old ref gets called with null before it's called with the new value (or the same component instance again). If you store the instance on your component, this effect should be unobservable as long as your component is mounted, but it prevents memory leaks. If you want to do something with in the ref handler, you should check if it's null.
Thanks for the information! I think this might be worth mentioning in the docs.

Related discussion:
text: It's as simple as assigning a `ref` attribute to anything returned from `render` such as: <del> ```html <input ref={ function(component){ React.findDOMNode(component).focus();} } /> ``` </del> <ins> ```html render: function() { return <TextInput ref={(c) => this._input = c} } />; }, componentDidMount: function() { this._input.focus(); }, ``` or ```html render: function() { return ( <TextInput ref={function(input) { if (input != null) { input.focus(); } }} /> ); }, ``` Note that when the referenced component is unmounted and whenever the ref changes, the old ref will be called with `null` as an argument. This prevents memory leaks in the case that the instance is stored, as in the first example. Note that when writing refs with inline function expressions as in the examples here, React sees a different function object each time so on every update, ref will be called with `null` immediately before it's called with the component instance. </ins> ## Completing the Example
Code change:
Issue with the reproducible example . Full build contains non-standard iterator. Theoretical, it can be to ES in the future, it can be (or already ) to another libraries. should take into account possibility iterable numbers.
Well, the good news is that if this is already on enough pages, then introducing iterable numbers may not be web compatible anyway. I think that this is only in DEV only code. Unfortunately a lot of pages incorrectly uses the DEV build of React.
"good news"

Related discussion:
text: * @param {*} parentType node's parent's type. */ function validateChildKeys(node, parentType) { <ins> if (typeof node !== 'object') { return; } </ins> if (Array.isArray(node)) { for (var i = 0; i < node.length; i++) { var child = node[i];
Code change:
Issue with the reproducible example . Full build contains non-standard iterator. Theoretical, it can be to ES in the future, it can be (or already ) to another libraries. should take into account possibility iterable numbers.
Well, the good news is that if this is already on enough pages, then introducing iterable numbers may not be web compatible anyway. I think that this is only in DEV only code. Unfortunately a lot of pages incorrectly uses the DEV build of React.
"good news"

Related discussion:
text: expect(console.error.argsForCall.length).toBe(0); }); <ins> it('should not enumerate enumerable numbers (#4776)', function() { /*eslint-disable no-extend-native */ Number.prototype['@@iterator'] = function() { throw new Error('number iterator called'); }; /*eslint-enable no-extend-native */ try { void ( <div> {5} {12} {13} </div> ); } finally { delete Number.prototype['@@iterator']; } }); </ins> });
Code change:
Issue with the reproducible example . Full build contains non-standard iterator. Theoretical, it can be to ES in the future, it can be (or already ) to another libraries. should take into account possibility iterable numbers.
Well, the good news is that if this is already on enough pages, then introducing iterable numbers may not be web compatible anyway. I think that this is only in DEV only code. Unfortunately a lot of pages incorrectly uses the DEV build of React.
"good news"

Related discussion:
text: ); }); <ins> it('should not enumerate enumerable numbers (#4776)', function() { /*eslint-disable no-extend-native */ Number.prototype['@@iterator'] = function() { throw new Error('number iterator called'); }; /*eslint-enable no-extend-native */ try { var instance = ( <div> {5} {12} {13} </div> ); var traverseFn = jasmine.createSpy(); traverseAllChildren(instance.props.children, traverseFn, null); expect(traverseFn.calls.length).toBe(3); expect(traverseFn).toHaveBeenCalledWith( null, 5, '.0' ); expect(traverseFn).toHaveBeenCalledWith( null, 12, '.1' ); expect(traverseFn).toHaveBeenCalledWith( null, 13, '.2' ); } finally { delete Number.prototype['@@iterator']; } }); </ins> });
Code change:
I'm still quite new to React, but I guess this is a bug in the React framework introduced in 0.14. Seems like all listeners attached with JSX are broken in native Android browser for Android LTE 4.3, when compiling code with NODEENV development. Everything works fine with NODEENV production compilation. I've tracked it down to being related to ReactErrorUtils, that in development mode do guards on events. The source code: If I simply remove that part of code after compiling the React app, the listeners starts working again. I guess this is not intentional, but instead a bug? To reproduce problem in Android LTE 4.3 (code that works in e.g. Chrome Browser): Using the pre-compiled Getting Started lib
Hm. That's unfortunate. I guess we'll try to find a feature test for this and patch it.

Related discussion:
text: * real browser event. */ if (typeof window !== 'undefined' && <del> typeof window.dispatchEvent === 'function' && typeof Event === 'function') { </del> <ins> typeof window.dispatchEvent === 'function') { </ins> var fakeNode = document.createElement('react'); ReactErrorUtils.invokeGuardedCallback = function(name, func, a, b) { var boundFunc = func.bind(null, a, b); fakeNode.addEventListener(name, boundFunc, false); <del> fakeNode.dispatchEvent(new Event(name)); </del> <ins> var evt = document.createEvent('Event'); evt.initEvent(name, false, false); fakeNode.dispatchEvent(evt); </ins> fakeNode.removeEventListener(name, boundFunc, false); }; }
Code change:
Oddly enough, the two examples below are not equal as I thought they would be. The error is as follows: I'm assuming that is because the function as assuming an optional callback. But I would expect your code to do a typeof check, and not just a defined check. Can we change it to do a check? I can submit a PR.
Well, the typecheck happens with that exact typecheck, just not directly in forceupdate. Here's forceUpdate: and where the invariant happens: FWIW, is not the same as due to an important distinction. The former makes a new function that is bound but it will pass along any arguments. The latter also is a new function but it explicitly doesn't pass any arguments. So the former gets the event passed along while the latter just drops it. The event isn't callable, thus the invariant. We need to do the typecheck so I guess we could discuss whether we keep it as an invariant or a warning. But it is a misuse of the API.
To follow up on that, the more "equal" thing would be: Which should throw the same error that you see with your first bind example.
Correct. Yes, I understand all of that. It wasn't toooo hard for me to understand what is happening. And it is a misuse of the API. So I guess, I would consider adding the argument type to the invariant to help make it clearer? Something more like: It's kind of moot. But It confused me for a second. Might confuse others also.

Related discussion:
text: invariant( typeof callback === 'function', 'enqueueCallback(...): You called `setProps`, `replaceProps`, ' + <del> '`setState`, `replaceState`, or `forceUpdate` with a callback that ' + 'isn't callable.' </del> <ins> '`setState`, `replaceState`, or `forceUpdate` with a callback of type ' + '%s. A function is expected', typeof callback === 'object' && Object.keys(callback).length && Object.keys(callback).length < 20 ? typeof callback + ' (keys: ' + Object.keys(callback) + ')' : typeof callback </ins> ); var internalInstance = getInternalInstanceReadyForUpdate(publicInstance);
Code change:
Oddly enough, the two examples below are not equal as I thought they would be. The error is as follows: I'm assuming that is because the function as assuming an optional callback. But I would expect your code to do a typeof check, and not just a defined check. Can we change it to do a check? I can submit a PR.
Well, the typecheck happens with that exact typecheck, just not directly in forceupdate. Here's forceUpdate: and where the invariant happens: FWIW, is not the same as due to an important distinction. The former makes a new function that is bound but it will pass along any arguments. The latter also is a new function but it explicitly doesn't pass any arguments. So the former gets the event passed along while the latter just drops it. The event isn't callable, thus the invariant. We need to do the typecheck so I guess we could discuss whether we keep it as an invariant or a warning. But it is a misuse of the API.
To follow up on that, the more "equal" thing would be: Which should throw the same error that you see with your first bind example.
Correct. Yes, I understand all of that. It wasn't toooo hard for me to understand what is happening. And it is a misuse of the API. So I guess, I would consider adding the argument type to the invariant to help make it clearer? Something more like: It's kind of moot. But It confused me for a second. Might confuse others also.

Related discussion:
text: invariant( typeof callback === 'function', 'enqueueCallback(...): You called `setProps`, `replaceProps`, ' + <del> '`setState`, `replaceState`, or `forceUpdate` with a callback that ' + 'isn't callable.' </del> <ins> '`setState`, `replaceState`, or `forceUpdate` with a callback of type ' + '%s. A function is expected', typeof callback === 'object' && Object.keys(callback).length && Object.keys(callback).length < 20 ? typeof callback + ' (keys: ' + Object.keys(callback) + ')' : typeof callback </ins> ); if (internalInstance._pendingCallbacks) { internalInstance._pendingCallbacks.push(callback);
Code change:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.

Related discussion:
text: */ function createLinkTypeChecker(linkType) { var shapes = { <del> value: typeof linkType === 'undefined' ? </del> <ins> value: linkType === undefined ? </ins> React.PropTypes.any.isRequired : linkType.isRequired, requestChange: React.PropTypes.func.isRequired,
Code change:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.

Related discussion:
text: var initialState = this.getInitialState ? this.getInitialState() : null; if (__DEV__) { // We allow auto-mocks to proceed as if they're returning null. <del> if (typeof initialState === 'undefined' && </del> <ins> if (initialState === undefined && </ins> this.getInitialState._isMockFunction) { // This is probably bad practice. Consider warning here and // deprecating this convenience.
Code change:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.

Related discussion:
text: if (type && type.defaultProps) { var defaultProps = type.defaultProps; for (propName in defaultProps) { <del> if (typeof props[propName] === 'undefined') { </del> <ins> if (props[propName] === undefined) { </ins> props[propName] = defaultProps[propName]; } }
Code change:
Introduction I found a bug on resolving default props when component props have property with HTMLAllCollection. React ignores value and uses default value (it should take that collection). isIE9OrLower (look at the end of topic) is simple function to test Internet Explorer in version 9 or lower. Simple use case: Chrome/Firefox/modern IE (yeah, i know....) returns HTMLAllColection (as ), but old IE returns true. HTMLAllCollection is weird collection: Source of bug and fix release: 0.14.7 file: line: 9149 code (bug): if (typeof props[propName] === 'undefined') { code (fix): if (props[propName] === undefined) { Btw, === undefined is faster than typeof === 'undefined' on Chrome and IE. Reproduction Open in Firefox / Chrome / IE10 or higher. Fiddle: Raw: Workaround Change to
Haha, browsers suck. Want to submit a PR? It looks like we do that thing unnecessarily in a few places in the React codebase. Note that we do need to use typeof if the binding might not exist, so we need to look at each case individually to make sure the change is valid there.
I went through the react repo configuration (build, tests execution). Fix didn't break anything, but so far I didn't find solution to make good test (phantomjs doesn't have property). (HTMLAllCollection) is probably the only exception to the typeof and is not a html standard. Any suggestions to the unit test for this fix/improvement?
As long as you tested it manually and it worked in IE, I think we can accept this change without a unit test.
Fixed in
lol what even
I can't reproduce being in IE 8 or IE 9 on Windows 7, either in standards or quirks mode. What am I missing?
IE < 10 is fine. Problem occurs when using modern browser like Chrome, Firefox, IE = 10 or Edge. They returns . component prop as in Chrome. will compare your prop with default prop (which is ). on Chrome is so React treats it as missing value. Default prop () will be selected. the end, prop will be always set to on modern browser in this case.
Oh! Sorry I totally misread. Yes I can repro this.

Related discussion:
text: var range = document.selection.createRange().duplicate(); var start, end; <del> if (typeof offsets.end === 'undefined') { </del> <ins> if (offsets.end === undefined) { </ins> start = offsets.start; end = start; } else if (offsets.start > offsets.end) {