jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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.
Code change:
} } while (nextEffect !== null) { <ins> if (__DEV__) { setCurrentFiber(nextEffect); } </ins> const effectTag = nextEffect.effectTag; if (effectTag & (Update | Callback)) {

Related discussion:
text: I've noticed a strange bug with the react redux opt-in. If i use it with a connected class component, everything is ok: If i use it with a connected functional component that use with , i obtain a strange error: in method. I create a codepen to reproduce the issue: PS: Sorry for the cors error, but i don't find the way to add as cdn
I believe the issue here is that expects the second argument to be a function that returns the reference: See: for more information about the API of the hook. Maybe the error thrown could be more clear?
You're right, accept a function as second argument. A warning on wrong argument type could be a good idea.
Ill take this issue on
Sure
i get TypeError: React.useImperativeMethods is not a function in 16.8.0-alpha.1 but when back to 16.7.0-alpha.2 not get this error
The hook was renamed in this PR: Most likely between the 16.7 alpha and 16.8 alpha
Yeah, it was renamed.
yes it work good after rename it where i can get changes between alpha version ?
Commit log. We don't write changelogs for alphas.
I'm taking this in since we want to get Hooks out sooner.
alright np
Code change:
const MAX_SIZE = 500; const PAGE_SIZE = 50; <del> function createRecord<K, V>(key: K): EmptyRecord<K, V> { </del> <ins> function createRecord<K>(key: K): EmptyRecord<K> { </ins> return { status: Empty, suspender: null,

Related discussion:
text: In we landed a change to the Flow types in , making the types for the various types recursive with their and properties. On that PR we may have been running an older version of Flow - I'm not having luck finding the record of when Flow ran for that PR, so not sure. In any case, that PR was merged even though it had the recursive Flow type definitions, plus one or more Flow errors which were unrelated and not detected. The problem with the recursive type definitions is that recent versions of Flow will go into an infinite loop if they try to infer types which are recursive. The solution may be to add more detail to those types, but to unblock things we temporarily made them looser type definitions.
Code change:
return newHead; } <del> function load<V>(emptyRecord: EmptyRecord, suspender: Promise<V>) { const pendingRecord: PendingRecord<V> = (emptyRecord: any); </del> <ins> function load<K, V>(emptyRecord: EmptyRecord<K>, suspender: Promise<V>) { const pendingRecord: PendingRecord<K, V> = (emptyRecord: any); </ins> pendingRecord.status = Pending; pendingRecord.suspender = suspender; suspender.then( value => { // Resource loaded successfully. <del> const resolvedRecord: ResolvedRecord<V> = (pendingRecord: any); </del> <ins> const resolvedRecord: ResolvedRecord<K, V> = (pendingRecord: any); </ins> resolvedRecord.status = Resolved; resolvedRecord.suspender = null; resolvedRecord.value = value;

Related discussion:
text: In we landed a change to the Flow types in , making the types for the various types recursive with their and properties. On that PR we may have been running an older version of Flow - I'm not having luck finding the record of when Flow ran for that PR, so not sure. In any case, that PR was merged even though it had the recursive Flow type definitions, plus one or more Flow errors which were unrelated and not detected. The problem with the recursive type definitions is that recent versions of Flow will go into an infinite loop if they try to infer types which are recursive. The solution may be to add more detail to those types, but to unblock things we temporarily made them looser type definitions.
Code change:
var propName = propertyInfo.propertyName; // Must explicitly cast values for HAS_SIDE_EFFECTS-properties to the // property type before comparing; only `value` does and is string. <del> // Must set `value` property if it is not null and not yet set. </del> if (!propertyInfo.hasSideEffects || <del> ('' + node[propName]) !== ('' + value) || !node.hasAttribute(propertyInfo.attributeName)) { </del> <ins> ('' + node[propName]) !== ('' + value)) { </ins> // Contrary to `setAttribute`, object properties are properly // `toString`ed by IE8/9. node[propName] = value;

Related discussion:
text: Appears to be working in Firefox but at least Chrome & Safari are broken. Should be a really recent regression so very few possible changes to blame... Easiest repo: the todo list on our homepage.
Just a heads up but this still seems to be an issue even on 15.4.1. I've been struggling to reproduce this because it seems to be some sort of ninja bug. Nevertheless, I was wondering if anyone is still dealing with this problem?
I haven't seen anything.
I'm still seeing this issue.
Please open a new issue with a simplified repro case if you're still seeing this!
Code change:
</span> {isEditable ? ( <EditableValue <del> dataType={dataType} </del> <ins> initialValue={value} </ins> overrideValueFn={((overrideValueFn: any): OverrideValueFn)} path={path} <del> initialValue={value} </del> /> ) : ( <span className={styles.Value}>{displayValue}</span>

Related discussion:
text: Do you want to request a feature or report a bug? Report a bug What is the current behavior? The hook's value is shown as in React DevTools if the value is a string or a number. Clicking on the bug icon prints the correct values to console. ! 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. CodeSandbox: Direct link to page so you can see the DevTools: What is the expected behavior? The DevTools should show the correct value of the hook. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.9.0. Google Chrome [Version 77.0.3865.90 (Official Build) (64-bit)] running on Linux x64. This issue appeared after version 4.1.0 (9/19/2019) of the DevTools Chrome extension. Might be same bug as but this one appears without any complicated reproduction steps.
Looks like the issue also appears with boolean values.
Having the same problem. The extension worked fine after I downgraded React to version 16.8.6
I think the only significant difference between React v16.8 and v16.9 is that v16.9 injects the function DevTools uses to support editable hooks (in other words, DevTools is using a different code path when you run v16.8 vs v16.9). I think that means this bug is probably related to somehow. Will dig in more.
Should be fixed by
This fix will be released with 4.1.1 (sometime soon)
This fix has just been published to NPM and posted to Chrome/Firefox as v4.1.1
Code change:
do { lastID = internalGetID(current); current = current.parentNode; <del> invariant( current != null, 'findFirstReactDOMImpl(...): Unexpected detached subtree found when ' + 'traversing DOM from node `%s`.', nodeID ); </del> <ins> if (current == null) { // The passed-in node has been detached from the container it was // originally rendered into. return null; } </ins> } while (lastID !== reactRootID); if (current === containersByReactRootID[reactRootID]) {

Related discussion:
text: Since upgrading from beta3 to rc1 I've seen this error a few times in production. Haven't been able to trace the source yet though. cc
I was unmounting a root during a keyboard event which caused this to happen. I think this has always been a problem? Perhaps we've only been lucky... leaving open just to be sure. EDIT: Could it make sense to have something along the lines of ? Allowing you to schedule things to occur as soon as the current transaction ends.
This invariant was new in this release. We also hit one case at FB that I haven't yet investigated. Probably need to change something for the final release.
I have seen this on RC1 can't find a sequence of actions to repeat it.
I'm running into this issue as well when conditionally rendering based on state. Not sure how to boil it down to a simple reproducible bug report yet.
My issue only happens when I am leveraging FastClick. Didn't happen before 0.14.
I've found it is because the events are handled in a different order with fastclick, so the batching gets weird...
e.g. click gets fired before touchEnd, so click handler setState to remove subtree, and then react tries to do something with it in touch end perhaps?
Code change:
do { lastID = internalGetID(current); current = current.parentNode; <del> invariant( current != null, 'findFirstReactDOMImpl(...): Unexpected detached subtree found when ' + 'traversing DOM from node `%s`.', nodeID ); </del> <ins> if (current == null) { // The passed-in node has been detached from the container it was // originally rendered into. return null; } </ins> } while (lastID !== reactRootID); if (current === containersByReactRootID[reactRootID]) {

Related discussion:
text: In this repro, I created 2 buttons and only one is rendered at a time. One button's click handler is hooked up to React's synthetic "click" event while the other is hooked up to the native "click" event. Even though only one button is rendered at a time, a single click is triggering both click events. This bug can be hit by apps that mix React components with non-React controls (e.g. jQuery UI). I reproed this in Chrome with React 0.13.2. to the button labeled "One" Expected: There's a button rendered labeled "Two" Actual: The rendered button still has the label "One" If you open the console, you'll see "goToTwo" and "goToOne" which indicates that the "One" button's click handler ran and then the "Two" button's click handler ran (even though we never saw button "Two"").
I experimented more and came up with another repro: In this one, you click on a button with a native "click" handler which causes the button to go away and an input field to be rendered. It results in this exception: From these 2 repros, it seems something strange is going on when calling from within a native "click" handler.
It works if you add to the event handler.
Thanks for the workaround. Is the behavior without the by design? It looks like the bad behavior is being caused by the rerender happening synchronously within the native "click" handler.
This looks bad. We don't do a great job interacting with native events. Sebastian wrote a post about this once-upon-a-time, how native and synthetic event systems are, by and large, not interoperable. Even so, I can't see a reason we should fatal like this. Do you understand what's going wrong here? What a fix might look like?
This happens when we handle a click event from a node that's been removed in between when the event is triggered and when React receives it. How should we deal with the case that events fire on detached elements? Should we ignore events for nodes that aren't in the document? I don't think the bug is easily fixable otherwise because we don't have the old event handler after the reconcile that removes that node.
Here are some additional details about the impact of the bug.
Code change:
do { lastID = internalGetID(current); current = current.parentNode; <del> invariant( current != null, 'findFirstReactDOMImpl(...): Unexpected detached subtree found when ' + 'traversing DOM from node `%s`.', nodeID ); </del> <ins> if (current == null) { // The passed-in node has been detached from the container it was // originally rendered into. return null; } </ins> } while (lastID !== reactRootID); if (current === containersByReactRootID[reactRootID]) {

Related discussion:
text: It sounds like this bug is likely to trigger when you use a non-React component (e.g. jQuery UI) in a React single page application and the non-React component triggers a navigation within the app.
Thanks for an excellent bug report and good repro case! I think this happens because we use the "root id" to determine which element was clicked. In the repro case there is no "key" as part of the root ID for two reasons: 1) It is not a child of a container (multichild) so it doesn't get a key to the root ID. 2) It doesn't have a unique key and doesn't need one because it the button is of a different type. If I make sure that a key is used as part of the root ID the problem is solved: So the problem in the repro isn't that we're firing on a removed node, it is that we're firing the event on the new node. This would be solved if we used a unique ID per instance to identify event handlers instead of a generate root that is non-unique. Which I think we wanted to do anyway. Is there another repro that shows a different issue?
Code change:
Markdown is a simple way to format your text inline. For example, surrounding text with asterisks will make it emphasized. <del> First, add the third-party **Showdown** library to your application. This is a JavaScript library which takes Markdown text and converts it to raw HTML. This requires a script tag in your head (which we have already included in the React playground): </del> <ins> First, add the third-party library **marked** to your application. This is a JavaScript library which takes Markdown text and converts it to raw HTML. This requires a script tag in your head (which we have already included in the React playground): </ins> ```html{7} <!-- index.html -->

Related discussion:
text: Since copy+pasting our code makes it too easy for people to XSS themselves, lets just add a comment in there about it.
PR at - let me know if that's what you had in mind!
My intuition is that it makes more sense to fix the example (call a sanitization library) or to change the example completely (demonstrate something else that is safer). It looks really bad to have a security warning on the homepage of the react site. Makes it seem like our framework encourages unsafe operations, rather than a safe-by-default way of doing things.
Should switch the demo to use a different library like markdown-js that escapes everything and doesn't support HTML:
markdown-js looks good. First attempt: ,output Code licensed if someone wants to turn this into a coherent example; I've signed the CLA.
That's a good suggestion too :) - what are your thoughts? I'm happy to change the example to use like people have suggested above. nice usage example :+1:
Uh yea, that sounds fine to me. This behavior is definitely non-standard markdown but it's an example so not a big deal. We should probably do the same for the tutorial while we're here. And it's on cdnjs so that's all pretty easy:
Just going to use marked instead, which I'm already familiar with and has an option to sanitize input.
Code change:
); } break; <ins> case 'option': transaction.getReactMountReady().enqueue( optionPostMount, this ); </ins> } return mountImage;

Related discussion:
text: Appears to be working in Firefox but at least Chrome & Safari are broken. Should be a really recent regression so very few possible changes to blame... Easiest repo: the todo list on our homepage.
Just a heads up but this still seems to be an issue even on 15.4.1. I've been struggling to reproduce this because it seems to be some sort of ninja bug. Nevertheless, I was wondering if anyone is still dealing with this problem?
I haven't seen anything.
I'm still seeing this issue.
Please open a new issue with a simplified repro case if you're still seeing this!
Code change:
"private": true, "scripts": { "build": "cross-env NODE_ENV=production yarn run build:chrome && yarn run build:firefox && yarn run build:edge", <del> "build:dev": "cross-env NODE_ENV=development yarn run build:chrome && yarn run build:firefox && yarn run build:edge", </del> <ins> "build:dev": "cross-env NODE_ENV=development yarn run build:chrome:dev && yarn run build:firefox:dev && yarn run build:edge:dev", </ins> "build:chrome": "cross-env NODE_ENV=production node ./chrome/build", "build:chrome:crx": "cross-env NODE_ENV=production node ./chrome/build --crx", "build:chrome:dev": "cross-env NODE_ENV=development node ./chrome/build",

Related discussion:
text: <!-- Please provide a clear and concise description of what the bug is. Include screenshots if needed. Please test using the latest version of the relevant React packages to make sure your issue has not already been fixed. --React Dev Tools version: 4.6.0 I'm not sure there is a problem with within package, or it's just my misunderstand how it works, but script create production build. Command above runs a each script (per browser) in which is set to . run in creates minified version of files. where has set to . Each step in should be replaced from to
Send a PR? This does look odd.
Sure, I'll take a look at it tomorrow, it's looks odd and incorrectly but need to check there isn't any trap with that
Code change:
return markup; }, <ins> _constructComponent: function(publicProps, publicContext) { if (__DEV__) { ReactCurrentOwner.current = this; try { return this._constructComponentWithoutOwner(publicProps, publicContext); } finally { ReactCurrentOwner.current = null; } } else { return this._constructComponentWithoutOwner(publicProps, publicContext); } }, _constructComponentWithoutOwner: function(publicProps, publicContext) { var Component = this._currentElement.type; if (shouldConstruct(Component)) { return new Component(publicProps, publicContext, ReactUpdateQueue); } else { return Component(publicProps, publicContext, ReactUpdateQueue); } }, </ins> performInitialMountWithErrorHandling: function( renderedElement, nativeParent,

Related discussion:
text: There appears to have been a change in how is generated between 0.13 and 0.14 which is causing a number of our shallow rendered tests to fail when upgrading because the deepEquals fails on the property. Here is a simple example component which exhibits the issue.
I've been seeing some similar issues with shallow rendering. My current (messy - sorry!) workaround is this: Let me know if that helps! My version currently breaks some of the Jest tests, but I'm happy to work on this some more and submit a PR.
Thank you very much for this, it's been a tremendous help! While this solved the problem for my test case above it still failed on a large number of our more complex tests. I've been iterating on it and once I have all of our tests passing I'll add the updated version.
Here is the updated workaround, it works for our 238 tests of varying complexity but I'd be interested to see if it passes all of your tests as well.
Awesome! If you don't mind trying, what happens if you do and then use the earlier ?
Much cleaner thanks, I guess I was in my head too much :)
I prefer applying a monkey patch, until we have this fixed in react by wrapping TestUtils in my own module:
This should be fixed by .
Code change:
<script type="text/javascript" src="/react/js/react.js"></script> <script type="text/javascript" src="/react/js/JSXTransformer.js"></script> <script type="text/javascript" src="/react/js/live_editor.js"></script> <del> <script type="text/javascript" src="/react/js/showdown.js"></script> </del> </head> <body>

Related discussion:
text: Since copy+pasting our code makes it too easy for people to XSS themselves, lets just add a comment in there about it.
PR at - let me know if that's what you had in mind!
My intuition is that it makes more sense to fix the example (call a sanitization library) or to change the example completely (demonstrate something else that is safer). It looks really bad to have a security warning on the homepage of the react site. Makes it seem like our framework encourages unsafe operations, rather than a safe-by-default way of doing things.
Should switch the demo to use a different library like markdown-js that escapes everything and doesn't support HTML:
markdown-js looks good. First attempt: ,output Code licensed if someone wants to turn this into a coherent example; I've signed the CLA.
That's a good suggestion too :) - what are your thoughts? I'm happy to change the example to use like people have suggested above. nice usage example :+1:
Uh yea, that sounds fine to me. This behavior is definitely non-standard markdown but it's an example so not a big deal. We should probably do the same for the tutorial while we're here. And it's on cdnjs so that's all pretty easy:
Just going to use marked instead, which I'm already familiar with and has an option to sanitize input.