jiebi/CodeConvo huggingface dataset:
Code change:
nextEffect = nextEffect.nextEffect; } <ins> if (__DEV__) { resetCurrentFiber(); } </ins> } function commitPassiveEffects(root: FiberRoot, firstEffect: Fiber): void {

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:
``` To make an uncontrolled component, `defaultValue` is used instead. <ins> > Note: > > You can pass an array into the `value` attribute, allowing you to select multiple options in a `select` tag: `<select multiple={true} value={['B', 'C']}>`. </ins>

Related discussion:
text: From : cc
Fixed.
Reopening because new docs don't have that info, and it is confusing. We should re-add it.
I am looking to make my first contribution and would like to fix this issue.
I also opened a PR for this on last week, restoring the original note. I notes for discussion on a more thorough example on the PR, like the current example has, but have not done much beyond that. Do we think that such an example would be beneficial? I almost think not, since the difference is just treating as an array with , but I'm curious to hear everyone else's thoughts on that.
There hasn't been any further discussion in PR or on this issue in the last two months, so is that PR all we need to do for this? cc
Sorry. We’ve been busy with a rewrite for React 16, and haven’t been actively reviewing the PRs.
Fixed in
No sweat, I figured as much. React 16 was absolutely worth it, great work!
Code change:
// Simulate `input.valueAsNumber`. IE9 does not support it var valueAsNumber = parseFloat(node.value, 10) || 0; <del> // eslint-disable-next-line if (value != valueAsNumber) { </del> <ins> if ( // eslint-disable-next-line value != valueAsNumber || // eslint-disable-next-line (value == valueAsNumber && node.value != value) ) { </ins> // Cast `value` to a string to ensure the value is set correctly. While // browsers typically do this as necessary, jsdom doesn't. node.value = '' + value;

Related discussion:
text: for example, when the original value is '.98', we need format it to '0.98'. but it is not take effect
This is working for me -
your example is not same with mine. the key is .98 can't be formated to 0.98. Because as number they are equal.
Just housekeeping. Do we close out issues before a release with the fix has shipped or wait?
typically I close the issue once the has been merged into master
Awesome, thanks! This should land in the next minor release of React:
Code change:
let effect = firstEffect; do { <ins> if (__DEV__) { setCurrentFiber(effect); } </ins> if (effect.effectTag & Passive) { let didError = false; let error;

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:
When a user interacts with a React view, the view sends an action (usually represented as a JavaScript object with some fields) through the dispatcher, which notifies the various stores that hold the application's data and business logic. When the stores change state, they notify the views that something has updated. This works especially well with React's declarative model, which allows the stores to send updates without specifying how to transition views between states. <del> Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An [example of this architecture](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is available, along with more [detailed documentation](http://facebook.github.io/react/docs/flux-overview.html) and a [tutorial](http://facebook.github.io/react/docs/flux-todo-list.html). Look for more examples to come in the future. </del> <ins> Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An [example of this architecture](https://github.com/facebook/flux/tree/master/examples/flux-todomvc) is available, along with more [detailed documentation](http://facebook.github.io/flux/docs/overview.html) and a [tutorial](http://facebook.github.io/flux/docs/todo-list.html). Look for more examples to come in the future. </ins>

Related discussion:
text: We're basically keeping 2 copies of documentation in sync and failing. We should just point at and We should maybe make the permalinks on our site redirect or just link offsite. We should also look for links in our docs pointing to those pages and update.
cc
also cc
Definitively agreed, we should link all the traffic to the dedicated website. See the Complementary section on Flux website
Code change:
expect(nodeValueSetter.mock.calls.length).toBe(expected); } <del> if (ReactDOMFeatureFlags.useCreateElement) { renderWithValueAndExpect(undefined, 0); renderWithValueAndExpect('', 1); renderWithValueAndExpect('foo', 2); renderWithValueAndExpect('foo', 2); renderWithValueAndExpect(undefined, 3); renderWithValueAndExpect(null, 3); renderWithValueAndExpect('', 4); renderWithValueAndExpect(undefined, 4); } else { renderWithValueAndExpect(undefined, 0); // This differs because we will have created a node with the value // attribute set. This means it will hasAttribute, so we won't try to // set the value. renderWithValueAndExpect('', 0); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect(undefined, 2); renderWithValueAndExpect(null, 2); // Again, much like the initial update case, we will always have the // attribute set so we won't set the value. renderWithValueAndExpect('', 2); renderWithValueAndExpect(undefined, 2); } </del> <ins> renderWithValueAndExpect(undefined, 0); renderWithValueAndExpect('', 0); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect('foo', 1); renderWithValueAndExpect(undefined, 2); renderWithValueAndExpect(null, 2); renderWithValueAndExpect('', 2); renderWithValueAndExpect(undefined, 2); </ins> }); it('should not incur unnecessary DOM mutations for boolean properties', function() {

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:
injectCode(rendererCode); } <del> // Inject a `__REACT_DEVTOOLS_GLOBAL_HOOK__` global so that React can detect that the // devtools are installed (and skip its suggestion to install the devtools). injectCode( ';(' + installHook.toString() + '(window))' + saveNativeValues + detectReact, ); </del> <ins> // Inject a __REACT_DEVTOOLS_GLOBAL_HOOK__ global for React to interact with. // Only do this for HTML documents though, to avoid e.g. breaking syntax highlighting for XML docs. if (document.contentType === 'text/html') { injectCode( ';(' + installHook.toString() + '(window))' + saveNativeValues + detectReact, ); } </ins>

Related discussion:
text: Steps to reproduce: 1) Disable all add-ons in Firefox 2) Open an URL that points to a XML file 3) AS EXPECTED: A pretty-printed XML is shown 4) Enable the React DevTools Add-on 5) Open the XML file again 6) FAIL: Only the content inside the XML tags are shown Using Firefox Developer Edition 72.0b6 on macOS 10.15.2
I am able to reproduce the behavior described using Firefox Developer Edition (72.0b1) but regular Firefox (71.0) does not exhibit the buggy behavior. I don't believe this is something that the React DevTools add-on should be able to cause, since syntax highlighting is a built-in browser feature. There is no error in the console (or the add-on if I inspect it). Just enabling the extension is enough to immediately "break" pretty-print for XML files, e.g. I believe that this may be a Firefox Developer Edition bug. It's probably not something that an extension should be able to cause. I'll open a bug on their end: cc
Thanks! I see the same with and the LastPass add-on
It's unclear what Firefox is going to do on their end about this, but it seems like we can make this better by checking in the content script if is "text/xml" before injecting any tags.
This will be fixed in the next release.
FYI this issue should be fixed in v4.4 (released today)
Code change:
* @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];

Related discussion:
text: 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"
Code change:
<ul> {% for item in section.items %} <li> <del> <a href="/react/docs/{{ item.id }}.html"{% if page.id == item.id %} class="active"{% endif %}> {{ item.title }} </a> </del> <ins> {{ item | sidebar_item_link}} </ins> {% if item.subitems %} <ul> {% for subitem in item.subitems %} <li> <del> <a href="/react/docs/{{ subitem.id }}.html"{% if page.id == subitem.id %} class="active"{% endif %}> {{ subitem.title }} </a> </del> <ins> {{ item | sidebar_item_link}} </ins> </li> {% endfor %} </ul>

Related discussion:
text: We're basically keeping 2 copies of documentation in sync and failing. We should just point at and We should maybe make the permalinks on our site redirect or just link offsite. We should also look for links in our docs pointing to those pages and update.
cc
also cc
Definitively agreed, we should link all the traffic to the dedicated website. See the Complementary section on Flux website
Code change:
export default function EditableValue({ className = '', <del> dataType, </del> initialValue, overrideValueFn, path,

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:
}); }, []); <del> return useMemo( () => ({ editableValue, hasPendingChanges: smartStringify(initialValue) !== editableValue, isValid, parsedValue, reset, update, }), [editableValue, initialValue, isValid, parsedValue], ); </del> <ins> return { editableValue, hasPendingChanges: smartStringify(initialValue) !== editableValue, isValid, parsedValue, reset, update, }; </ins> } export function useIsOverflowing(

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:
error => { // Resource failed to load. Stash the error for later so we can throw it // the next time it's requested. <del> const rejectedRecord: RejectedRecord = (pendingRecord: any); </del> <ins> const rejectedRecord: RejectedRecord<K> = (pendingRecord: any); </ins> rejectedRecord.status = Rejected; rejectedRecord.suspender = null; rejectedRecord.error = error;

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:
]); }); <ins> it('should shallow render a functional component', function() { function SomeComponent() { return ( <div> <span className="child1" /> <span className="child2" /> </div> ); } var shallowRenderer = ReactTestUtils.createRenderer(); var result = shallowRenderer.render(<SomeComponent />); expect(result.type).toBe('div'); expect(result.props.children).toEqual([ <span className="child1" />, <span className="child2" />, ]); }); </ins> it('should throw for invalid elements', function() { var SomeComponent = React.createClass({ render: function() {

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:
var node = ReactDOM.findDOMNode(stub); expect(node.innerHTML).toBe('foobar'); }); <ins> it('should set attribute for empty value', function() { var container = document.createElement('div'); var option = ReactDOM.render(<option value="" />, container); expect(option.hasAttribute('value')).toBe(true); expect(option.getAttribute('value')).toBe(''); ReactDOM.render(<option value="lava" />, container); expect(option.hasAttribute('value')).toBe(true); expect(option.getAttribute('value')).toBe('lava'); }); </ins> });

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:
miss: A => Promise<V>, missArg: A, ): V { <del> const record: Record<V> = accessRecord(resourceType, key); </del> <ins> const record: Record<K, V> = accessRecord(resourceType, key); </ins> switch (record.status) { case Empty: // Load the requested resource.

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:
key: K, value: V, error: null, <del> next: Record<K, V> | null, previous: Record<K, V> | null, </del> <ins> next: any, // TODO: (issue #12941) previous: any, // TODO: (issue #12941) /** * Proper types would be something like this: * next: Record<K, V> | null, * previous: Record<K, V> | null, */ </ins> |}; <del> type RejectedRecord<K, V> = {| </del> <ins> type RejectedRecord<K> = {| </ins> status: 3, suspender: null, key: K, value: null, error: Error, <del> next: Record<K, V> | null, previous: Record<K, V> | null, </del> <ins> next: any, // TODO: (issue #12941) previous: any, // TODO: (issue #12941) /** * Proper types would be something like this: * next: Record<K, V> | null, * previous: Record<K, V> | null, */ </ins> |}; type Record<K, V> = <del> | EmptyRecord<K, V> </del> <ins> | EmptyRecord<K> </ins> | PendingRecord<K, V> | ResolvedRecord<K, V> <del> | RejectedRecord<K, V>; </del> <ins> | RejectedRecord<K>; </ins> type RecordCache<K, V> = {| map: Map<K, Record<K, V>>, head: Record<K, V> | null, tail: Record<K, V> | null, <ins> size: number, </ins> |}; // TODO: How do you express this type with Flow?

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.