jiebi/CodeConvo huggingface dataset:
Code change:
Nor sure what that means other than that the tests are flakey :'(
https://travis-
https://travis-

Related discussion:
text: function getJSReport(browser){ return browser <del> .waitForCondition("typeof window.jasmine != 'undefined'", 5e3) </del> <ins> .waitFor(wd.asserters.jsCondition("typeof window.jasmine != 'undefined'"), 5e3, 50) </ins> .fail(function(error){ throw Error("The test page didn't load properly. " + error); }) <del> .waitForCondition("typeof window.jasmine.getJSReport != 'undefined'", 10e3) .waitForCondition("window.postDataToURL.running <= 0", 30e3) </del> <ins> .waitFor(wd.asserters.jsCondition("typeof window.jasmine.getJSReport != 'undefined'"), 60e3, 100) .waitFor(wd.asserters.jsCondition("window.postDataToURL.running <= 0"), 30e3, 500) </ins> .eval("jasmine.getJSReport().passed"); }
Code change:
Nor sure what that means other than that the tests are flakey :'(
https://travis-
https://travis-

Related discussion:
text: urls.unshift('../node_modules/es5-shim/es5-shim.js'); } <del> var cacheBust = '?_=' + Date.now().toString(36); </del> <ins> var cacheBust = '?_=' + (+new Date).toString(36); </ins> for (var urls_index = -1, urls_length = urls.length; ++urls_index < urls_length;) { document.write('<script src="' + urls[urls_index] + cacheBust + '"></script>');
Code change:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.

Related discussion:
text: * @protected */ setState: function(partialState, callback) { <ins> invariant( typeof partialState === 'object' || partialState == null, 'setState(...): takes an object of state variables to update.' ); if (__DEV__){ if (partialState == null) { console.warn( 'setState(...): You passed an undefined or null state object; ' + 'instead, use forceUpdate().' ); } } </ins> // Merge with `_pendingState` if it exists, otherwise with existing state. this.replaceState( merge(this._pendingState || this.state, partialState),
Code change:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.

Related discussion:
text: checkMergeArrayArgs: function(one, two) { invariant( Array.isArray(one) && Array.isArray(two), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge arrays, instead got %s and %s.', one, two </ins> ); },
Code change:
Passing a function with some properties (simply the wrong thing) into yields rather cryptic: especially since the message says it is not the caller's fault.
One could add an invariant to But it is strange that the invariants in and don't mention arrays and objects, respectively.
is also a very contextual name (I have no idea what the author meant). I agree that these messages could be better.

Related discussion:
text: checkMergeObjectArg: function(arg) { invariant( !isTerminal(arg) && !Array.isArray(arg), <del> 'Critical assumptions about the merge functions have been violated. ' + 'This is the fault of the merge functions themselves, not necessarily ' + 'the callers.' </del> <ins> 'Tried to merge an object, instead got %s.', arg </ins> ); },
Code change:
When I run jsx --watch src/ build/ it compiles the jsx files and create a file in the build directory. On the next jsx file modification, the jsx process crashes. Once the is present, jsx won't compile jsx files even when ran manually. I use OSX Maverick and jsx 0.8.13.
AFAIK this is a "bug" with or whatever JSX relies on to expose that feature. Just make sure to close the watch instance instead of just closing the terminal/powering down and it should be fine.
Does it work again if you remove the file?
Yes it does. Oh or wait, the crashing.
It seems like there are two ways of fixing this. We can either out why is not cleaning up the file when the process exits, or the functionality and just hope people don't accidentally have multiple processes targeting the same output directory. I'm pretty comfortable with option 2, honestly. Thoughts,
Yeah, no lock seems fine for me, it could warn if it was found perhaps? Another thing to mention that has been happening to me, I'm using React through a Linux VM and accessing the filesystem through samba. When saving a file it immediately triggers a recompile before the file has finished saving, causing it to error. Shortly after it recompiles it again, so no harm, but it's worth noting.
I'm fine with no locking. I didn't even know that existed. Do what works!

Related discussion:
text: "url": "https://github.com/facebook/react" }, "dependencies": { <del> "commoner": "~0.8.14", </del> <ins> "commoner": "~0.9.0", </ins> "esprima-fb": "~2001.1001.0-dev-harmony-fb", "jstransform": "~2.0.2" },
Code change:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

Related discussion:
text: var mocks = require('mocks'); <ins> var ExecutionEnvironment; </ins> var React; <ins> var ReactMarkupChecksum; </ins> var ReactMount; <ins> var ReactReconcileTransaction; </ins> var ReactTestUtils; var ReactServerRendering; <del> var ReactMarkupChecksum; var ExecutionEnvironment; </del> var ID_ATTRIBUTE_NAME;
Code change:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

Related discussion:
text: beforeEach(function() { require('mock-modules').dumpCache(); React = require('React'); <ins> ReactMarkupChecksum = require('ReactMarkupChecksum'); </ins> ReactMount = require('ReactMount'); ReactTestUtils = require('ReactTestUtils'); <ins> ReactReconcileTransaction = require('ReactReconcileTransaction'); </ins> ExecutionEnvironment = require('ExecutionEnvironment'); ExecutionEnvironment.canUseDOM = false; ReactServerRendering = require('ReactServerRendering'); <del> ReactMarkupChecksum = require('ReactMarkupChecksum'); </del> var DOMProperty = require('DOMProperty'); ID_ATTRIBUTE_NAME = DOMProperty.ID_ATTRIBUTE_NAME;
Code change:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

Related discussion:
text: 'a valid ReactComponent.' ); }); <ins> it('allows setState in componentWillMount without using DOM', function() { var Component = React.createClass({ componentWillMount: function() { this.setState({text: 'hello, world'}); }, render: function() { return <div>{this.state.text}</div>; } }); ReactReconcileTransaction.prototype.perform = function() { // We shouldn't ever be calling this on the server throw new Error('Browser reconcile transaction should not be used'); }; var markup = ReactServerRendering.renderComponentToString( <Component /> ); expect(markup.indexOf('hello, world') >= 0).toBe(true); }); </ins> }); });
Code change:
After upgrading from React 0.10 to 0.11 our handler fires during server-side rendering and ends up in which requires access to the DOM, i.e. : Redacted stack trace:
I have the same problem
I'm having the same problem. I was so happy to see you finally the hrefLang attribute support and tried to upgrade immediately. Unfortunately this problem is keeping me from upgrading.
FYI, we worked around it by using which might work in your case too depending on your use case.
Wow this sounds like a big regression. Can you construct a simple repro case?
I will try but I probably won’t be able to until Sunday the earliest. Frankly, the error doesn’t happen with for every handler we have, so there might be something we’re doing wrong.
This might happen always if you setState within a componentWillMount? Agree that we need to fix this.
For me it happens when I do setState in componentWillMount. Will try to come up with the simplest repro case.
Oh, setState() is probably going through ReactUpdates which is using the (browser-specific as of 0.11) ReactReconcileTransaction I think.
Yes, we are using in the failing handler. Is that a bad practice?
maybe? why are you doing that vs ?
Here’s the part of the stack trace ( is the offending handler):
This is the most simple example that reproduces the problem:
Trying to figure out if the right move is to fix in or instead forbid in in favor of . Thoughts
The former; we've always said this is supported.
but why do we support it? seems like "more than one way to do it"...
One use case is computing something based on props in both componentWillMount and componentWillReceiveProps; you can make a helper and call it in both places.
does the same thing, no?
Based on your example, I can see now that calling is not very elegant in but disallowing it but would be a breaking change based on the current documentation: I’m ok with a breaking change in releases as long as it’s documented à la change.
We're going to put out 0.11.1 with this (and a couple other ride-alongs). Thanks for bringing it to our attention!
:+1: Thanks :smile:
Hi guys! The issue referenced above looks (reactjs/react-rails) related to this one... input welcome!

Related discussion:
text: // componentDidUpdate) but we need to check here too in order to catch // updates enqueued by setState callbacks. while (dirtyComponents.length) { <ins> var allUnmounted = true; for (var i = 0, l = dirtyComponents.length; i < l; i++) { if (dirtyComponents[i].isMounted()) { allUnmounted = false; break; } } if (allUnmounted) { // All the "dirty" components are unmounted, which probably means that // they were marked dirty due to setState calls in componentWillMount // handlers and the components are currently in the process of mounting. // `runBatchedUpdates` will be a noop. In that case, initializing the // DOM-dependent ReactReconcileTransaction is thus not what we want to // do, especially when using server rendering, so we skip it. dirtyComponents.length = 0; return; } </ins> var transaction = ReactUpdatesFlushTransaction.getPooled(); transaction.perform(runBatchedUpdates, null, transaction); ReactUpdatesFlushTransaction.release(transaction);
Code change:
At the end, there is a confusing explanation about "Duplicated data from props" in the section "What Shouldn’t Go in State?": Perhaps what is trying to be said is something like:
Ah, perhaps what they're really referring to is basically "edit pages", where you might want to diff the before and after, so that you can send only the changed variables. But it really reads quite weirdly, especially for beginners.
This change is needed. I'm new to React and just did a Google search on that part of the documentation for clarification and it came up with this page. I'm guessing that what you've interpreted it to mean is correct, as it makes sense that way.

Related discussion:
text: * **Computed data:** Don't worry about precomputing values based on state — it's easier to ensure that your UI is consistent if you do all computation within `render()`. For example, if you have an array of list items in state and you want to render the count as a string, simply render `this.state.listItems.length + ' list items'` in your `render()` method rather than storing it on state. * **React components:** Build them in `render()` based on underlying props and state. <del> * **Duplicated data from props:** Try to use props as the source of truth where possible. Because props can change over time, it's appropriate to store props in state to be able to know its previous values. </del> <ins> * **Duplicated data from props:** Try to use props as the source of truth where possible. One valid use to store props in state is to be able to know it's previous values, because props can change over time. </ins>
Code change:
Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.

Related discussion:
text: invariant( one[key] === undefined, 'mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: %s', </del> <ins> 'Tried to merge two objects with the same key: `%s`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.', </ins> key ); one[key] = value;
Code change:
Understandably general given that this is used to merge a couple things, but the actual use case is when or (or but shh) is used in a mixin and the component and both return an object with the same key. We should make this error mention something about those methods so people have an idea of where to look instead of them coming to IRC and being (rightfully) confused.

Related discussion:
text: instance = ReactTestUtils.renderIntoDocument(instance); }).toThrow( 'Invariant Violation: mergeObjectsWithNoDuplicateKeys(): ' + <del> 'Tried to merge two objects with the same key: x' </del> <ins> 'Tried to merge two objects with the same key: `x`. This conflict ' + 'may be due to a mixin; in particular, this may be caused by two ' + 'getInitialState() or getDefaultProps() methods returning objects ' + 'with clashing keys.' </ins> ); });
Code change:
Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1

Related discussion:
text: <ins> /** * Copyright 2014-2015, Facebook, Inc. * All rights reserved. * * This source code is licensed under the BSD-style license found in the * LICENSE file in the root directory of this source tree. An additional grant * of patent rights can be found in the PATENTS file in the same directory. * * @emails react-core */ 'use strict'; require('mock-modules') .dontMock('shallowEqual'); var shallowEqual; describe('shallowEqual', function() { beforeEach(function() { shallowEqual = require('shallowEqual'); }); it('returns false if either argument is null', function() { expect(shallowEqual(null, {})).toBe(false); expect(shallowEqual({}, null)).toBe(false); }); it('returns true if both arguments are null or undefined', function() { expect(shallowEqual(null, null)).toBe(true); expect(shallowEqual(undefined, undefined)).toBe(true); }); it('returns true if arguments are shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2, c: 3} ) ).toBe(true); }); it('returns false if first argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2, c: 3}, {a: 1, b: 2} ) ).toBe(false); }); it('returns false if second argument has too many keys', function() { expect( shallowEqual( {a: 1, b: 2}, {a: 1, b: 2, c: 3} ) ).toBe(false); }); it('returns false if arguments are not shallow equal', function() { expect( shallowEqual( {a: 1, b: 2, c: {}}, {a: 1, b: 2, c: {}} ) ).toBe(false); }); }); </ins>
Code change:
Without , is , which causes this line in to throw. Fix is to make shallowEqual bail if either argument is falsey (or not an object if we want to be very safe).
Is this with PureRenderMixin?
Yes, I meant to link to the jsbin: ,js,console,output I'm putting together a PR now.
It is potentially worth noting that getInitialState is likely to become required for stateful components in the near future. See It is already the case that any component calling should ideally be specifying a .
I definitely think it makes sense to make required for stateful components +1

Related discussion:
text: if (objA === objB) { return true; } <ins> if (!objA || !objB) { return false; } </ins> var key; // Test for A's keys different from B. for (key in objA) {
Code change:
! Edits were made last week to this page, maybe it was broken accidentally?
I guess you use https, but the page loads a script over http and that gets blocked. I made a pull request to fix this . I couldn't test it, so fingers crossed that it is right.
I though we were going to remove this page and let this live entirely in the react-magic repo?
The scripts live in the react-magic repo, but I think we'll keep the page on the React site as it's still really useful there.

Related discussion:
text: <div class="jsxCompiler"> <h1>HTML to JSX Compiler</h1> <div id="jsxCompiler"></div> <del> <script src="http://reactjs.github.io/react-magic/htmltojsx.min.js"></script> </del> <ins> <script src="https://reactjs.github.io/react-magic/htmltojsx.min.js"></script> </ins> <script src="js/html-jsx.js"></script> </div>