jiebi/CodeConvo huggingface dataset:
Code change:
const [parsedValue, setParsedValue] = useState(initialValue); const [isValid, setIsValid] = useState(initialIsValid); <del> const reset = useCallback(() => { setEditableValue(smartStringify(initialValue)); setParsedValue(initialValue); setIsValid(initialIsValid); }, []); </del> <ins> const reset = useCallback( () => { setEditableValue(smartStringify(initialValue)); setParsedValue(initialValue); setIsValid(initialIsValid); }, [initialValue, initialIsValid], ); </ins> const update = useCallback(newValue => { let isNewValueValid = false;

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:
disableInputAttributeSyncing, enableTrustedTypesIntegration, deferPassiveEffectCleanupDuringUnmount, <ins> warnAboutShorthandPropertyCollision, </ins> } = require('ReactFeatureFlags'); // In www, we have experimental support for gathering data

Related discussion:
text: I a "bug" today that made me spent 1h figuring out what was going on: I'm using an external component that accepts a prop in order to set the of the root element, but this same component also accepts a prop which I wasn't passing, and by default, it was set to . The result: React didn't throw an error nor a warning, however, the resulting element in the DOM didn't contain either or , and since the element had a default coming from a CSS class, it took me a while to figure out why the color that I was passing wasn't being applied, and instead it was using the one from the CSS class. See: What I reported above was the case. I other cases as a bonus, as when I was playing with this they also seemed weird to me. On I define the same properties, but because I change the order, it works. On the toggleable ones, initially I can see the background, but after changing it never appears anymore. I'm not sure if I created those extra "test cases" correctly. My main concern is really around static1 not outputting anything on the console as a warning. Related issues: I wonder if ( should have covered this?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
it seems that the bot automatically closed the issue, but this still needs action. I took a time to investigate it, and I realized that the work Sophie has done covers this case, but there's just one problem: it's disabled under a . I built it locally and flipped the flag, and it works: I can see the helpful warning. It was flagged in , and as per the PR, the original intention was to unflag it on the next minor. Since then we had at least 4 new minor versions, but it is still flagged. Is there a special reason for that or was it just forgotten? tagging you since you this flag, so I'm hoping you can give context here.
Can we unflag this?
This was released.
Code change:
// 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> });

Related discussion:
text: 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.
Code change:
"benchmark": "~1.0.0", "browserify": "~3.20.0", "coverify": "~1.0.4", <del> "envify": "~1.0.1", </del> <ins> "envify": "~1.2.0", </ins> "es3ify": "~0.1.2", "es5-shim": "~2.3.0", "grunt": "~0.4.2",

Related discussion:
text: React 0.8 React 0.9 I think this is because of switched to in 1.0.0. I submitted a to envify which uses instead of recast. This brings us back to 1.5s and delivers the same advantages as recast version (preserves code formatting): I think this is blocker for 0.9.0.
What command are you running, and in what directory? I'm having trouble reproducing the slow-down with just .
Code change:
charSet: null, challenge: null, checked: MUST_USE_PROPERTY | HAS_BOOLEAN_VALUE, <ins> cite: null, </ins> classID: null, className: null, cols: HAS_POSITIVE_NUMERIC_VALUE,

Related discussion:
text: is currently only supported as element, not as attribute in . Since it is unknown to react it's thrown away on render.
I'd like to take this!
It's yours Let me know if you have any questions.
Cool! :+1:
Can we get this into a PR pretty please? :o)
Umm this was merged 3 years ago already...
my apologies. I came across this from a Google search after using cite in blockquote in React 16.8.6 was throwing an error for me at build time. I'll have to dig deeper into the cause.
Code change:
<h3>A Component Using External Plugins</h3> <p> React is flexible and provides hooks that allow you to interface with <del> other libraries and frameworks. This example uses Showdown, an external </del> <ins> other libraries and frameworks. This example uses **marked**, an external </ins> Markdown library, to convert the textarea's value in real-time. </p> <div id="markdownExample"></div> </div> </div> <del> <script type="text/javascript" src="js/examples/hello.js"></script> <script type="text/javascript" src="js/examples/timer.js"></script> <script type="text/javascript" src="js/examples/todo.js"></script> <script type="text/javascript" src="js/examples/markdown.js"></script> </del> <ins> <script type="text/javascript" src="/react/js/marked.min.js"></script> <script type="text/javascript" src="/react/js/examples/hello.js"></script> <script type="text/javascript" src="/react/js/examples/timer.js"></script> <script type="text/javascript" src="/react/js/examples/todo.js"></script> <script type="text/javascript" src="/react/js/examples/markdown.js"></script> </ins> </section> <hr class="home-divider" /> <section class="home-bottom-section">

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:
export const disableJavaScriptURLs = false; export const disableInputAttributeSyncing = false; export const exposeConcurrentModeAPIs = __EXPERIMENTAL__; <del> export const warnAboutShorthandPropertyCollision = false; </del> <ins> export const warnAboutShorthandPropertyCollision = true; </ins> export const enableSchedulerDebugging = false; export const enableDeprecatedFlareAPI = false; export const enableFundamentalAPI = false;

Related discussion:
text: I a "bug" today that made me spent 1h figuring out what was going on: I'm using an external component that accepts a prop in order to set the of the root element, but this same component also accepts a prop which I wasn't passing, and by default, it was set to . The result: React didn't throw an error nor a warning, however, the resulting element in the DOM didn't contain either or , and since the element had a default coming from a CSS class, it took me a while to figure out why the color that I was passing wasn't being applied, and instead it was using the one from the CSS class. See: What I reported above was the case. I other cases as a bonus, as when I was playing with this they also seemed weird to me. On I define the same properties, but because I change the order, it works. On the toggleable ones, initially I can see the background, but after changing it never appears anymore. I'm not sure if I created those extra "test cases" correctly. My main concern is really around static1 not outputting anything on the console as a warning. Related issues: I wonder if ( should have covered this?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
it seems that the bot automatically closed the issue, but this still needs action. I took a time to investigate it, and I realized that the work Sophie has done covers this case, but there's just one problem: it's disabled under a . I built it locally and flipped the flag, and it works: I can see the helpful warning. It was flagged in , and as per the PR, the original intention was to unflag it on the next minor. Since then we had at least 4 new minor versions, but it is still flagged. Is there a special reason for that or was it just forgotten? tagging you since you this flag, so I'm hoping you can give context here.
Can we unflag this?
This was released.
Code change:
expect(console.error.argsForCall.length).toBe(0); }); <ins> it('should not enumerate enumerable numbers (#4776)', function() { /*eslint-disable no-extend-native */ Number.prototype['@@iterator'] = function() { throw new Error('number iterator called'); }; /*eslint-enable no-extend-native */ try { void ( <div> {5} {12} {13} </div> ); } finally { delete Number.prototype['@@iterator']; } }); </ins> });

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:
]); }); <ins> it('warns for bad useImperativeHandle first arg', () => { const {useImperativeHandle} = React; function App() { useImperativeHandle({ focus() {}, }); return null; } expect(() => { expect(() => { ReactTestRenderer.create(<App />); }).toThrow('create is not a function'); }).toWarnDev([ 'Expected useImperativeHandle() first argument to either be a ' + 'ref callback or React.createRef() object. ' + 'Instead received: an object with keys {focus}.', 'Expected useImperativeHandle() second argument to be a function ' + 'that creates a handle. Instead received: undefined.', ]); }); it('warns for bad useImperativeHandle second arg', () => { const {useImperativeHandle} = React; const App = React.forwardRef((props, ref) => { useImperativeHandle(ref, { focus() {}, }); return null; }); expect(() => { ReactTestRenderer.create(<App />); }).toWarnDev([ 'Expected useImperativeHandle() second argument to be a function ' + 'that creates a handle. Instead received: object.', ]); }); </ins> // https://github.com/facebook/react/issues/14022 it('works with ReactDOMServer calls inside a component', () => { const {useState} = React;

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:
<meta property="og:description" content="A JavaScript library for building user interfaces" /> <link rel="shortcut icon" href="/react/favicon.ico"> <ins> <link rel="alternate" type="application/rss+xml" title="{{ site.name }}" href="{{ site.url }}{{ site.baseurl }}/feed.xml"> </ins> <link rel="stylesheet" href="/react/css/react.css"> <link rel="stylesheet" href="/react/css/syntax.css">

Related discussion:
text: As it is known (but ), React's SyntheticEvent is pooled. This is confusing for many users as they don't understand why the event starts to behave strangely when used in an async callback, like inside a , a or a callback. There has already been an attempt to solve this problem here: The code of SyntheticEvent's default methods is: It may make sense to be more defensive because calling on a pooled event will raise . It would be more useful to add a check like:
To illustrate the problem in not being defensive, I would give you this commit that has made it into production as a workaround in React-tappable: Basically the user is trying to assign an empty function to a SyntheticEvent that as been put back in the pool (the call to persist was from another PR at the same time). And we were basically 3 concurrent PR to try different solutions to the exact same problem.
As the person who made the PR in a panic, I did find the code that broke in react itself. the preventDefault method tries to call the method on . A simple if check for in the method, and a no-op if null would be a great fix to this problem. Similar to how setState is handled on an unmounted component.
I think React should not swallow this error and be fail fast, because this does not make any sense to preventDefault in an async callback (because the default already has been applied), React should rather throw an error. But this is only my opinion, because the browser behavior with dom events is not fail fast and swallow that bad usage of preventDefault. I mean the browser does not throw an error when we do: It simply has no effect (like what you suggest) I don't like this and would rather change the behavior of both React and the browser, but I don't think I can do much on my own... Maybe at least React could issue a warning in DEV env?
Yeah, I think warning is appropriate here.
A warning would be great!
Just wonder what kind of message should be put into this warning. If event pooling is not going to be documented (will it?), it may be strange to explain the pooling system inside a warning no?
Yes, event pooling should/will be documented. Feel free to submit a PR. We should add a warning to let the user know that the event has been returned to the pool and so invoking methods on it makes no sense.
Code change:
<meta property="og:description" content="A JavaScript library for building user interfaces" /> <link rel="shortcut icon" href="/react/favicon.ico"> <ins> <link rel="alternate" type="application/rss+xml" title="{{ site.name }}" href="{{ site.url }}{{ site.baseurl }}/feed.xml"> </ins> <link rel="stylesheet" href="/react/css/react.css"> <link rel="stylesheet" href="/react/css/syntax.css">

Related discussion:
text: Once the docs are written, we can add a link to the end of the warning.
Got a PR for this! Would really appreciate some feedback.
Code change:
inst._wrapperState = {selected: selected}; }, <ins> postMountWrapper: function(inst) { // value="" should make a value attribute (#6219) var props = inst._currentElement.props; if (props.value != null) { var node = ReactDOMComponentTree.getNodeFromInstance(inst); node.setAttribute('value', props.value); } }, </ins> getNativeProps: function(inst, props) { var nativeProps = Object.assign({selected: undefined, children: undefined}, props);

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:
<ins> module Jekyll module SidebarItemFilter def sidebar_item_link(item) pageID = @context.registers[:page]["id"] itemID = item["id"] href = item["href"] || "/react/docs/#{itemID}.html" className = pageID == itemID ? ' class="active"' : '' return "<a href="#{href}"#{className}>#{item["title"]}</a>" end end end Liquid::Template.register_filter(Jekyll::SidebarItemFilter) </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:
miss: A => Promise<V>, missArg: A, ): void { <del> const record: Record<V> = accessRecord(resourceType, key); </del> <ins> const record: Record<K, V> = accessRecord(resourceType, key); </ins> switch (record.status) { case Empty: // Warm the cache.

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.