jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Note: if the issue is about documentation or the website, please file it at: --Do you want to request a feature or report a bug? Bug What is the current behavior? Bailing out doesn't work properly in lazy components with default props. It seems we're incorrectly . 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: What is the expected behavior? In the example above, shouldn't have been called when the button is clicked. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
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!
Can you turn this into a failing test please?
Sure.
Send a PR?
OK
Feel free to add a fix if you know where the bug is

Related discussion:
text: } if (typeof instance.getSnapshotBeforeUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Snapshot;
Code change:
React version: 16.13.1 This code works fine when using plain , but fails: when is enabled: The warning is caused by an exception happened in this block: This is happening because module brings its own implementation of the object with slightly different behavior which requires context to be properly preserved. This one-line change should do the fix: This issue has also been reported to React-testing-library, which has similar code: Why should this be a fix in React and not in ESM? React relied on undocumented behavior of Node modules loader. It was never guaranteed that it will work without proper context. In fact, it will not work as expected if you try it with any non built-in module The current code in React may break in future if module will be replaced with anything else, or if changes their internal implementation.
Do you want to submit a PR It sounds like a reasonable thing for us to fix.
I could, however I am not sure about testing part. What kind of tests would you expect for this?

Related discussion:
text: const nodeRequire = module && module[requireString]; // assuming we're in node, let's try to get node's // version of setImmediate, bypassing fake timers if any. <del> enqueueTaskImpl = nodeRequire('timers').setImmediate; </del> <ins> enqueueTaskImpl = nodeRequire.call(module, 'timers').setImmediate; </ins> } catch (_err) { // we're in a browser // we can't use regular timers because they may still be faked
Code change:
<!-- 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. --Looks like you forgot about the debugger inside the React dev tools version: 4.8.0 (or install) the latest version of devtools devtools code will be stopped on the debugger inside ! If I open devtools with react dev tools extension it will stop every time on debugger inside It doesn't seem like it should be happening
Same here, I've had to disable the extension because of this... :smile:
Same for me.
Looks bad.
Same here
That's the guy you're looking for :D
Yes, but see the comment above it. :-) It is intentional, but this option should have been off by default.
As a temporary solution you can "blackbox" script in Chrome Dev Tools: !
You should also be able to go to Components tab, press Settings gear, add checkbox to Break on Warning, then do this again, and remove the checkbox as a temporary workaround.
I'll keep it open until we cut a release
Thanks
I've submitted a fix to Chrome addons. It should appear there in a few hours. If it doesn't work after updating to 4.8.1, try to clear your local storage (). I can't figure out how to submit it to FF store because something in our process has changed. So will be able to help us out there when he wakes up. :-)
Here's a step-by-step instruction for how to work around it while the fix is pending review: the Settings gear icon in the upper right corner <img width="1161" alt="Screenshot 2020-07-10 at 14 39 06" src="https://user-"the Debugging tab <img width="1275" alt="Screenshot 2020-07-10 at 14 39 13" src="https://user-"the checkmark next to Break on Warnings <img width="1273" alt="Screenshot 2020-07-10 at 14 39 20" src="https://user-"the checkmark next to Break on Warnings <img width="1286" alt="Screenshot 2020-07-10 at 14 39 25" src="https://user-"Now reload the page and you shouldn't be bothered by it.
Please refrain from "same" comments unless you have something new to say. They are not helpful and obscure the workaround ().
Update: The fix has been published to NPM as 4.81 The updated extension (with fix) is live for Firefox The updated extension is pending for Chrome Edge is still providing the previous version 4.7 (but an updated 4.8.1 is also pending for review)
We'll keep this issue open until the fix has been deployed on Chrome, but I'm going to lock it to prevent +1
1 is live in Chrome store now too, so I'm going to close this.

Related discussion:
text: return JSON.parse(raw); } } catch (error) {} <del> return true; </del> <ins> return false; </ins> } export function setBreakOnConsoleErrors(value: boolean): void {
Code change:
DevTools named hook parsing logic currently matches AST nodes using the original line number: But this may not be sufficient, as mentioned in comment
While we're on the subject: Column numbers in particular are where a lot of inconsistencies between tools/engines' representations occur and off-by-one errors creep in. V8, SpiderMonkey, JSC all use 1-based lines and 1-based columns in . Hermes follows the other engines for the most part but has its own thing going on for bytecode addresses (printed similarly to columns but 0-based). See the in React Native. VS Code uses 1-based lines and 1-based columns. The library (at least AFAIK from older versions) uses 1-based lines and 0-based columns in its API. ESTree/Babel ASTs use 1-based lines and 0-based columns. The Chrome DevTools protocol uses 0-based lines and 0-based columns. So I suspect we have an incorrect conversion already - we should fix it and signpost assumptions/conversions more clearly.
Reopening to address this follow up comment from

Related discussion:
text: return false; } <ins> // Column numbers are representated differently between tools/engines. // Error.prototype.stack columns are 1-based (like most IDEs) but ASTs are 0-based. // // In practice this will probably never matter, // because this code matches the 1-based Error stack location for the hook Identifier (e.g. useState) // with the larger 0-based VariableDeclarator (e.g. [foo, setFoo] = useState()) // so the ranges should always overlap. // // For more info see https://github.com/facebook/react/pull/21833#discussion_r666831276 column -= 1; </ins> if ( (line === start.line && column < start.column) || (line === end.line && column > end.column)
Code change:
DevTools named hook parsing logic currently matches AST nodes using the original line number: But this may not be sufficient, as mentioned in comment
While we're on the subject: Column numbers in particular are where a lot of inconsistencies between tools/engines' representations occur and off-by-one errors creep in. V8, SpiderMonkey, JSC all use 1-based lines and 1-based columns in . Hermes follows the other engines for the most part but has its own thing going on for bytecode addresses (printed similarly to columns but 0-based). See the in React Native. VS Code uses 1-based lines and 1-based columns. The library (at least AFAIK from older versions) uses 1-based lines and 0-based columns in its API. ESTree/Babel ASTs use 1-based lines and 0-based columns. The Chrome DevTools protocol uses 0-based lines and 0-based columns. So I suspect we have an incorrect conversion already - we should fix it and signpost assumptions/conversions more clearly.
Reopening to address this follow up comment from

Related discussion:
text: line: lineNumber, // Column numbers are representated differently between tools/engines. <ins> // Error.prototype.stack columns are 1-based (like most IDEs) but ASTs are 0-based. </ins> // For more info see https://github.com/facebook/react/issues/21792#issuecomment-873171991 column: columnNumber - 1, });
Code change:
Currently the CHANGELOG shows 4.3.0 as the latest version of , but at least on , there is not a 4.4.0. React version: n/a Changelog to version on Link to code example: n/a No 4.4.0 explanation in 0 explanation in
I think 4.4.0 was essentially a no-op release to correspond with React 18 release (though cc to confirm). Looking at what's changed in the package between the 4.3.0 release and Monday's 4.4.0 "release" I see: I believe this is the same thing as happened with the ESLint 4.2.0 release and React 17. I believe the "fix" here would be to just add a 4.4.0 release to the CHANGELOG that notes this.
Thanks so much That definitely seems like the right fix!

Related discussion:
text: <ins> ## 4.4.0 * No changes, this was an automated release together with React 18. </ins> ## 4.3.0 * Support ESLint 8. ([@MichaelDeBoey](https://github.com/MichaelDeBoey) in [#22248](https://github.com/facebook/react/pull/22248))
Code change:
<!-- 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 version: main branch "" in " and its " <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --The page is 404. The page should exist.
Fixed by

Related discussion:
text: The examples in the React repository are declared a bit differently than a third-party renderer would be. In particular, the `HostConfig` object mentioned above is never explicitly declared, and instead is a *module* in our code. However, its exports correspond directly to properties on a `HostConfig` object you'd need to declare in your code: * [React ART](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactART.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-art/src/ReactARTHostConfig.js) <del> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOMHostConfig.js) </del> <ins> * [React DOM](https://github.com/facebook/react/blob/main/packages/react-dom/src/client/ReactDOM.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-dom-bindings/src/client/ReactDOMHostConfig.js) </ins> * [React Native](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeRenderer.js) and its [host config](https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactNativeHostConfig.js) 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. If you have more questions please file an issue and we’ll try to help!