jiebi/CodeConvo huggingface dataset:
Change:
no longer works, and this causes all old fiddles like to break. We should fix it.
I've also noticed fiddles[1][2] linking to being broken. I assume they were/are linking to the same place, but it's something to keep in mind. [1] [2] (All the examples seem to be broken)
It will take a few minutes to deploy the site but hopefully this should be fixed now.
Unfortunately Recharts examples are broken because they don't specify the React version. So they accidentally "updated" to React 16 that has different file names. We could potentially fix this on our side by providing a fallback. But then, one of the most commonly used builds () doesn't even exist anymore. So this has to be fixed on their side anyway.

Discussion:
const config = { default: { patterns: ['src/**/*.js', 'www/**/*.js'], <del> ignore: ['**/third_party/**', '**/node_modules/**'], </del> <ins> ignore: [ '**/third_party/**', '**/node_modules/**', '**/jsfiddle-integration*.js', ], </ins> }, scripts: { patterns: ['scripts/**/*.js', 'fixtures/**/*.js'],

<ins> // Do not delete or move this file. // Many fiddles reference it so we have to keep it here. (function() { var tag = document.querySelector( 'script[type="application/javascript;version=1.7"]' ); if (!tag || tag.textContent.indexOf('window.onload=function(){') !== -1) { alert('Bad JSFiddle configuration, please fork the original React JSFiddle'); } tag.setAttribute('type', 'text/babel'); tag.textContent = tag.textContent.replace(/^//<![CDATA[/, ''); })(); </ins>  No newline at end of file

<ins> // Do not delete or move this file. // Many fiddles reference it so we have to keep it here. (function() { var tag = document.querySelector( 'script[type="application/javascript;version=1.7"]' ); if (!tag || tag.textContent.indexOf('window.onload=function(){') !== -1) { alert('Bad JSFiddle configuration, please fork the original React JSFiddle'); } tag.setAttribute('type', 'text/jsx;harmony=true'); tag.textContent = tag.textContent.replace(/^//<![CDATA[/, ''); })(); </ins>
Change:
As far as I can tell, the path to the UMD version of React 16 changed, which makes it impossible to test the latest version of React through the test fixtures. We probably need to add a condition to the react loader to change the path above a certain version:
did really resolve this? I thought the problem was the CDN paths we're using?
No. Sorry. I got the wrong issue :(
I fixed in . Still broken for 16 alphas but they’re pretty borked anyway. Might need to blacklist them somehow.
No problem. I a little work around in . It seemed about as good as a blacklist.

Discussion:
handleKeydown = e => { // only interesting in arrow key events <del> if (![37, 38, 39, 40].includes(e.keyCode)) return; </del> <ins> if ([37, 38, 39, 40].indexOf(e.keyCode) < 0) { return; } </ins> this.setState(({keydownCount}) => { return {
Change:
Hello, Today I have spotted the bug(?) in IE10/IE11: while setting the inner HTML on any element (, , ) using property the browser will raise an error . I use this with SSR, but the actual HTML received from the server is good, so probably there's a problem with func. Some code: where is some string that contains HTML. !
Hey! This was fixed in and is a known issue. A fix should be out in the next release. However thank you for the great write up!
React has been released. Please update , , and (if you use it) to this version and let us know if it solved the issue! We’d appreciate if you could test before Monday when we plan to get out.
Hi Dan, everything is working now, thank you!

Discussion:
} .example-enter.example-enter-active { <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> } ```

```css .example-leave { <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> transition: opacity .5s ease-in; }

.example-enter.example-enter-active, .example-leave { margin-left: 0; <del> opacity: 0.99; </del> <ins> opacity: 1; </ins> } .animateExample {
Change:
Reporting this since it says "If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving." and knowing the place of the most up-to-date examples would help me a lot. The issue template does not really fit here but I'm trying to follow it anyway. Do you want to request a feature or report a bug? Bug (In a README) What is the current behavior? In there are 3 links to reconciler configuration examples of , and . All 3 links are broken If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via or similar (template for React 16: , template for React 15: ). Just visit the  What is the expected behavior? Correct links I wanted to fix these in a PR but could only find an appropriate replacement for react-native here: Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Issue exists on -branch
The other ones are called just ReactDOM and ReactART. Please submit a PR.

Discussion:
## Practical Examples <del> * [React ART](https://github.com/facebook/react/blob/master/src/renderers/art/ReactARTFiberEntry.js) * [React DOM](https://github.com/facebook/react/blob/master/src/fb/ReactDOMFiberFBEntry.js) * [React Native](https://github.com/facebook/react/blob/master/src/renderers/native/ReactNativeFiberRenderer.js) </del> <ins> * [React ART](https://github.com/facebook/react/blob/master/packages/react-art/src/ReactART.js) * [React DOM](https://github.com/facebook/react/blob/master/packages/react-dom/src/client/ReactDOM.js) * [React Native](https://github.com/facebook/react/blob/master/packages/react-native-renderer/src/ReactNativeFiberRenderer.js) </ins> If these links break please file an issue and we’ll fix them. They intentionally link to the latest versions since the API is still evolving.
Change:
This is a follow-up to . The attribute on elements is currently supported, but it is configured as a attribute: This causes to render as The attribute supports strings though: This is very important for being able to configure the default camera selected on mobile devices.
Should be out in 16.1.1.
I have confirmed that updating to 16.1.1 fixes the issue in my project.

Discussion:
// autoFocus is polyfilled/normalized by AutoFocusUtils // autoFocus: HAS_BOOLEAN_VALUE, autoPlay: HAS_BOOLEAN_VALUE, <del> capture: HAS_BOOLEAN_VALUE, </del> <ins> capture: HAS_OVERLOADED_BOOLEAN_VALUE, </ins> checked: MUST_USE_PROPERTY | HAS_BOOLEAN_VALUE, cols: HAS_POSITIVE_NUMERIC_VALUE, contentEditable: HAS_STRING_BOOLEAN_VALUE,
Change:
Follow up from Here's one I found. These two invariants: are in a function that's behind a DEV block: I don't think this is intentional, but need to verify. There may be more. I'll use this issue to track while preserves existing behavior.
Here’s another difference: in development, putting a string ref on a functional component throws with: Stateless function components cannot have refs. but in production gives you: Element ref was specified as a string but no owner was set.

Discussion:
: emptyObject; const instance = new ctor(props, context); adoptClassInstance(workInProgress, instance); <del> checkClassInstance(workInProgress); </del> // Cache unmasked context so we can avoid recreating masked context unless necessary. // ReactFiberContext usually updates this cache but can't for newly-created instances.

workInProgress: Fiber, priorityLevel: PriorityLevel, ): void { <ins> if (__DEV__) { checkClassInstance(workInProgress); } </ins> const instance = workInProgress.stateNode; const state = instance.state || null;
Change:
It looks like this: It happened two times on random commits, and I don't see a pattern. Probably caused by me changing how tasks are distributed between parallel nodes in I don't understand why would try to run before a build exists though (if that's what's happening?)
I think this one would require some experience with CircleCI. I don't have any pointers as to where to start: I don't understand why it's failing myself. So it's not a very beginner-friendly issue (I marked the difficulty as medium for that reason).
Another example:
I want to work on this. After doing some research on circleci document, I didn't find the document said about parallel test and deployment sequence. I'm curious about how circleci deal with parallel test and deployment sequence. I think there are two situations: all parallel test finishes, run deployment sequence. If this is true, I think it won't cause current test error. container runs deployment after the container's test finished. I guess it is more likely in this case. Sometimes it passed, it's because node 2 already built file. Sometimes it failed because node 2 didn't build file yet. So I think maybe that's because each container will run deployment after that node test finished. If the situation is as above, I come up with two solutions. we want to keep current test flow, we can try to keep each node builds time balance. this test at first, then run other test parallel. reference link:
Only node 2 does a full build. So I don't understand how deployment on other nodes could work at all.
Or do nodes share the file system?
I think nodes share the file system. Otherwise, it should fail every time. It will be easier to debug if we can add more log, like current build time and .
Would it make sense to change the upload script to only run on the second node?
Yep, I think so, because in the document I can't ensure whether deployment stage is triggered after all parallel test finished.
Can we just put the deployment command right into the test command? Is there any benefit to separating them?
I think it's also workable, but may lead misunderstanding. Cause we put build process to test stage. Or we can try to use stage. Run at compile stage, so we can promise and stages have needed file.
The interesting part is our regular tests don't need compilation. If "compile" stage has to run before any other stages then we'll wait unnecessarily. I'd prefer to have a single script that does everything than to buy into CircleCI specific terminology unless it buys us something real good (e.g. parallelism was very useful). Maybe can try this:
OK, I understand your consideration. I think this fix will work. Just tell me if anything can help.

Discussion:
override: - ./scripts/circleci/test_entry_point.sh: parallel: true <del> deployment: staging: branch: /.*/ commands: - ./scripts/circleci/upload_build.sh </del>

COMMANDS_TO_RUN+=('./scripts/circleci/build.sh') COMMANDS_TO_RUN+=('yarn test-build --runInBand') COMMANDS_TO_RUN+=('yarn test-build-prod --runInBand') <ins> COMMANDS_TO_RUN+=('./scripts/circleci/upload_build.sh') </ins> fi if [ $((3 % CIRCLE_NODE_TOTAL)) -eq "$CIRCLE_NODE_INDEX" ]; then
Change:
I want to report a bug. When there is a var named opera with value null in window before loading react then react app crashes. Steps to reproduce: 1) Create a new app using create-react-app my-app 2) cd my-app && yarn start 3) Add one line (</script) just before closing body tag into file 4) The app crashes here. Couldn't reproduce on I think because problem appears if we execute BEFORE loading react. Expected behavior is to not crash. React v16.2.0 and Google Chrome Version 63.0.3239.84 (Official Build) (64-bit). Have no info about problematic behavior with previous versions of React.
Closed by

Discussion:
function isPresto() { const opera = window.opera; return ( <ins> opera !== null && </ins> typeof opera === 'object' && typeof opera.version === 'function' && parseInt(opera.version(), 10) <= 12
Change:
Do you want to request a feature or report a bug? Report a bug What is the current behavior? React sets (via attributes / defaultValue) on all inputs with and no value. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: (actual, React) (expected, vanilla DOM) What is the expected behavior? value attribute should be empty unless passed via props. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 15+, any browser.
cc
I think this happens because the default value reported by checkboxes and radios is "on", in absence of a value property/attribute. Unfortunately, for ~16 our controlled text input code "detatches" value by assigning it over: We have some updates on master that prevent this, but I'll prep a test case for it and send it out. I'm also working on a PR that isolates the controlled checked and controlled value code to help prevent accidents like this in the future.
Sent with Lucky number .
We now have a test to confirm that this works as intended on master. This should land in the next release of React.

Discussion:
// TODO: we should warn here. }); }); <ins> describe('checked inputs without a value property', function() { // In absence of a value, radio and checkboxes report a value of "on". // Between 16 and 16.2, we assigned a node's value to it's current // value in order to "dettach" it from defaultValue. This had the unfortunate // side-effect of assigning value="on" to radio and checkboxes it('does not add "on" in absence of value on a checkbox', function() { const container = document.createElement('div'); ReactDOM.render( <input type="checkbox" defaultChecked={true} />, container, ); const node = container.firstChild; expect(node.value).toBe('on'); expect(node.hasAttribute('value')).toBe(false); }); it('does not add "on" in absence of value on a radio', function() { const container = document.createElement('div'); ReactDOM.render(<input type="radio" defaultChecked={true} />, container); const node = container.firstChild; expect(node.value).toBe('on'); expect(node.hasAttribute('value')).toBe(false); }); }); </ins> });
Change:
Do you want to request a feature or report a bug? bug What is the current behavior? calls as and :  where by default is annotated as (green), as (red). What is the expected behavior? should pass the expected values into , the actual (received) values into of :

Discussion:
} else if (expectedMessages.length === 1) { errorMessage = 'Unexpected warning recorded: ' + <del> jestDiff(normalizedMessage, expectedMessages[0]); </del> <ins> jestDiff(expectedMessages[0], normalizedMessage); </ins> } else { errorMessage = 'Unexpected warning recorded: ' + <del> jestDiff([normalizedMessage], expectedMessages); </del> <ins> jestDiff(expectedMessages, [normalizedMessage]); </ins> } // Record the call stack for unexpected warnings.
Change:
Maybe I missed it but I don't see this case in DOM fixtures: Seems important because it's easy to accidentally gloss over it if we stop syncing attributes and have to edit a bunch of jsdom tests.
Hello I would be interested in working on this. Thanks
Maybe it will really cool feature

Discussion:
<option value="/email-inputs">Email Input</option> <option value="/selects">Selects</option> <option value="/textareas">Textareas</option> <ins> <option value="/progress">Progress</option> </ins> <option value="/input-change-events"> Input change events </option>

<ins> import Fixture from '../../Fixture'; import FixtureSet from '../../FixtureSet'; import TestCase from '../../TestCase'; const React = window.React; class ProgressFixture extends React.Component { state = {value: 0, max: 1, enabled: false, backwards: false}; startTest = () => { this.setState({enabled: true}, () => { this.progressIntervalId = setInterval(() => { if (this.state.backwards) { if (this.state.value > 0) { this.setState({value: this.state.value - this.state.max / 100}); } else { if (this.state.max === 10000) { this.resetTest(); } else { this.setState({max: this.state.max * 100, backwards: false}); } } } else { if (this.state.value < this.state.max) { this.setState({value: this.state.value + this.state.max / 100}); } else { this.setState({backwards: true}); } } }, 10); }); }; resetTest = () => { clearInterval(this.progressIntervalId); this.setState({value: 0, max: 1, enabled: false, backwards: false}); }; render() { return ( <FixtureSet title="Progress"> <TestCase title="Fill and reset progress bar"> <TestCase.Steps> <li>Press enable button</li> </TestCase.Steps> <TestCase.ExpectedResult> When enabled, bar value should increase from 0% to 100% and backwards during three step loop: 0-1, 0-100, 0-10000. Reset button stops loop, sets value to 0 and max to 1. </TestCase.ExpectedResult> <Fixture> <div className="control-box"> <fieldset> <legend>Controlled</legend> <progress value={this.state.value} max={this.state.max}></progress> <button onClick={ this.state.enabled ? this.resetTest : this.startTest }> {this.state.enabled ? 'Reset' : 'Enable'} </button> <br /> <span className="hint"> {' '} max: {JSON.stringify(this.state.max)} </span> <span className="hint"> {' '} value:{' '} {JSON.stringify( Math.round((this.state.value + Number.EPSILON) * 100) / 100 )} </span> </fieldset> </div> </Fixture> </TestCase> </FixtureSet> ); } } export default ProgressFixture; </ins>
Change:
I believe this should be a valid case, because throw.
Hmm, I just realized throw should not be used for valid business case (GraphQL endpoint was updated). Render nothing (and request app update) is the correct approach.
I think we shouldn't warn on this.

Discussion:
useState(); } `, <ins> ` // Valid because exceptions abort rendering function RegressionTest() { if (page == null) { throw new Error('oh no!'); } useState(); } `, </ins> ], invalid: [ {

// Compute `paths` and cache it. Guarding against cycles. cache.set(segment.id, null); <del> if (segment.prevSegments.length === 0) { </del> <ins> if (codePath.thrownSegments.includes(segment)) { paths = 0; } else if (segment.prevSegments.length === 0) { </ins> paths = 1; } else { paths = 0;

// Compute `paths` and cache it. Guarding against cycles. cache.set(segment.id, null); <del> if (segment.nextSegments.length === 0) { </del> <ins> if (codePath.thrownSegments.includes(segment)) { paths = 0; } else if (segment.nextSegments.length === 0) { </ins> paths = 1; } else { paths = 0;
Change:
Do you want to request a feature or report a bug? Bug What is the current behavior? Suspense adds display: none to all top level child elements in IE11. If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle () or CodeSandbox () example below: Code sandbox can't render in IE11 either, but in this example I would expect to not see IE11 because the div would have display: none on it. What is the expected behavior? To be visible and not have display: none on the children. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? I had to revert back to react-loadable to fix this.
Is it IE11 specific or a general bug? There’s a few general bugs we’re tracking right now.
IE specific, it worked on Chrome/Safari, but in IE11 the display: none; was left on all the child components. I was able to go and check that style off in the inspector and see the components were loaded just fine.
If I take your CodeSandbox, add react-app-polyfill/ie9 and edit the to compile for IE11 support: – then download that, build it locally, and deploy to at https://build-, then I get a page that successfully displays "hello world" when opened in IE11. !
Can you confirm if I'm doing anything different from what you tested?
Hmm I was hoping it would be as simple as that. But I guess it is more complicated. I'm using it with the router for lazyloading router components. Here is my file that was working everywhere except for IE.
Oh, I think I found the bug.
I love GitHub issues/prs. I can easily track the problem, what caused it, and how to fix it! I was looking for a fix and had one! Thank you!
any ideas when this fix might make it into a release?
PS: We love the work you do for us all!
Any updates to this?
can be fixed with polyfills. It´s described in this pull request
Thanks everyone for this.
The issue itself has been fixed (I think in 16.7).
I'm noticing this problem with react version Suspense/fallback adds a style and this doesn't get removed on IE 11. Works fine on Chrome though.

Discussion:
DOCUMENT_NODE, DOCUMENT_FRAGMENT_NODE, } from '../shared/HTMLNodeType'; <ins> import dangerousStyleValue from '../shared/dangerousStyleValue'; </ins> import type {DOMContainer} from './ReactDOM';

styleProp.hasOwnProperty('display') ? styleProp.display : null; <del> // $FlowFixMe Setting a style property to null is the valid way to reset it. instance.style.display = display; </del> <ins> instance.style.display = dangerousStyleValue('display', display); </ins> } export function unhideTextInstance(
Change:
! The only alternative is using chains which aren't very readable at their own.
I think you're making it more complicated than it needs to be. If it uses some prop like : However, note that this doesn't guarantee requests come in order. So a better solution would be: This is a good article that goes into more detail and has more useful examples: In longer term, we'll recommend Suspense for data fetching which will look more like and no effects. But in the meantime the code above works fine.
What if I need to close over ? (Or based on your example): Also where do the errors go that are thrown in that async function invocation? I'd need to it? Or try/catch the body of the async so the promise always resolves? Why not make useEffect take an async function if we'd have to wrap them all the time anyways?
I guess one can always just :
now I should use instead of into a React Component with Hooks. Scenario "initial unique call to a server": To accomplished this, DependencyList ( second argument of useEffect) in useEffect should every time an empty array otherwise the application will send every state change a fetch call to the server. it' means , this it the best practise to getData ` Full Code here <details
Please ask on StackOverflow and feel free to link to your question from here. We don’t use issues for support because answers get lost on GitHub.
supports being async so I think useEffect should accept a promise and automatically resolve it to avoid having to them.
It is an intentional design decision. The async/await model is a pitfall for effects in general (and has always been a pitfall in classes!) due to race conditions. In the longer term, Suspense will be the recommended data fetching solution, and you can do / there. But Suspense for data fetching is not ready yet.
As I explained above, is a bad idea because you don't know whether is still relevant. For example, if the user starts fetching one profile page but then switches to another profile. Then you're at the mercy of which request arrives first, and can show incorrect data. This kind of code would handle it correctly: I'm going to lock this issue as resolved to prevent further confusion. Here's a good article that answers your other questions (e.g. about loading states):

Discussion:
var ReactComponent = require('ReactComponent'); var ReactDOM = require('ReactDOM'); var ReactMount = require('ReactMount'); <ins> var ReactProps = require('ReactProps'); </ins> var ReactServerRendering = require('ReactServerRendering'); var ReactDefaultInjection = require('ReactDefaultInjection');

var React = { DOM: ReactDOM, <ins> Props: ReactProps, </ins> initializeTouchEvents: function(shouldUseTouch) { ReactMount.useTouchEvents = shouldUseTouch; },