jiebi/CodeConvo huggingface dataset:
Change:
'use strict'; <del> var exec = require('child_process').exec; </del> var jsxTask = require('./grunt/tasks/jsx'); var browserifyTask = require('./grunt/tasks/browserify'); var populistTask = require('./grunt/tasks/populist');

Discussion:
We're blocked on a few things here. Current JSHint is incompatible with what we do with template strings. I have a PR up there to mostly fix it but I bet there are more things. So even after that I think we'll want to switch to using ESLint. However that has its own set of problems as it is still working on ES6/JSX support (mostly blocked on other libraries at this point it seems). I have a PR () up to start using eslint, but there are a few rules disabled (because of incompatibilities on their end) which are really important and enabling them is a blocker for this. [x] Use eslint () [x] Enable all appropriate rules [ ] Add custom rules (namely, must use string literals for 2nd argument)
Change:
// effect even though we're bailing out, so that cWU/cDU are called. if (typeof instance.componentDidUpdate === 'function') { if ( <del> oldProps !== current.memoizedProps || </del> <ins> unresolvedOldProps !== current.memoizedProps || </ins> oldState !== current.memoizedState ) { workInProgress.effectTag |= Update;

Discussion:
<!-- 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
Change:
<del> #encoding: utf-8 require('json') # Because of build process, does not necessarily reflect directory path in the # repository. package = JSON.parse(File.read('../../package.json')) gemspec = Gem::Specification.new do |s| s.name = 'react-source' s.version = package['version'] s.license = 'BSD-3-Clause' s.homepage = 'https://github.com/facebook/react' s.summary = 'Ruby bridge to JSX & the React JavaScript library.' s.authors = ['Paul O’Shannessy'] s.email = ['paul@oshannessy.com'] s.files = Dir[ 'build/react.js', 'build/react.min.js', 'build/react-with-addons.js', 'build/react-with-addons.min.js', 'build/JSXTransformer.js', 'lib/react/source.rb' ] end </del>

Discussion:
I'm not sure how much value there really is in this. react-rails already stopped using it and just builds the files in itself. cc
(I'm currently running to find out how many there might be - looks like this script may take a day to hit the end point for every gem in the registry)
:+1: I made but it's just a toy :)
Change:
withoutStack: true, }); }); <ins> it('does not call lazy initializers eagerly', () => { let didCall = false; const Lazy = React.lazy(() => { didCall = true; return {then() {}}; }); <Lazy />; expect(didCall).toBe(false); }); </ins> });

Discussion:
<!-- 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: 17.0.0-rc.1 elements out of components, use them conditionally. if the components are dynamically imported. <!-- 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. --Link to code example: -- : : : : : <!-- Please provide a CodeSandbox (), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem. You may provide a screenshot of the application if you think it is relevant to your bug report. Here are some tips for providing a minimal example: --The chunk is imported eagerly, even though the component isn't immediately rendered. ! This doesn't happen in prod mode, or with React 16, or with components that are not -ed eagerly. This affects react-router, as it uses this pattern: AFAICT it doesn't break anything, but it is unexpected/confusing. components that are not rendered should not be dynamically imported.
Shorter test case: This is enough to trigger the dynamic import in dev mode.
Behavior changed between 16.13.1 and the first release after . ! !
This is triggered by in . I think this doesn't really make sense to call but we'd need to see why this change to was made. <img width="398" alt="Screenshot 2020-09-03 at 13 56 14" src="https://user-"<img width="367" alt="Screenshot 2020-09-03 at 13 56 18" src="https://user-"
The suspense protocol is just a function that may throw. That allows for low overhead abstractions to be wrapped. This change was to allow the init function to encapsulate the actual suspense mechanism and that data structure. Unfortunately there’s no way to query the status of something in the suspense protocol without triggering the fetch. Same as you can’t do: Without triggering a fetch. The solution might be to move validation of lazy until it’s rendered instead of in createElement. Also, sigh PropTypes.

Should the label be removed?
Should be fixed in . Please verify.
Works great now, thanks! Looking forward to the 17.0.0 release.
Change:
return JSXTransformer.transform(code).code; }, editorTabTitle: 'Live JSX Editor', <del> showCompiledJSTab: true </del> <ins> showCompiledJSTab: true, showLineNumbers: false </ins> }; },

Discussion:
is a tool for transforming jsx into js. If the supplied code contains syntax errors, the error displays an line number but since the code field doesn't have line numbers its hard to identify the actual line itself. !
Change:
LOCAL_EXTENSION_ID, } from './constants'; <ins> const IS_CHROME = getBrowserName() === 'Chrome'; </ins> const UNRECOGNIZED_EXTENSION_ERROR = 'React Developer Tools: You are running an unrecognized installation of the React Developer Tools extension, which might conflict with other versions of the extension installed in your browser. ' + 'Please make sure you only have a single version of the extension installed or enabled. ' +

Discussion:
React DevTools v4.20.0 in Firefox in Firefox Firefox DevTools error in console ! Every time
Change:
this._pendingCallbacks = null; this._pendingElement = null; <del> ReactComponentEnvironment.unmountIDFromEnvironment(this._rootNodeID); </del> // These fields do not really need to be reset since this object is no // longer accessible. this._context = null;

Discussion:
Logging and reveals: Which doesn't make sense (to me at least).
Can you log the too and something to distinguish the two renderComponent calls?
Updated, that makes more sense,
Change:
<ins> --- id: docs-mixins title: Mixins layout: docs prev: advanced-components.html next: api.html --- Mixins allow code to be shared between multiple React components. They are pretty similar to mixins in Python or traits in PHP. Let's look at a simple example: ```javascript var MyMixin = { getMessage: function() { return 'hello world'; } }; var MyComponent = React.createClass({ mixins: [MyMixin], render: function() { return <div>{this.getMessage()}</div>; } }); ``` A class can use multiple mixins, but no two mixins can define the same method. Two mixins can, however, implement the same [lifecycle method](component-lifecycle.html). In this case, each implementation will be invoked one after another. The only exception is the `shouldComponentUpdate` lifecycle method. This method may only be implemented once (either by a mixin or by the component). ```javascript var Mixin1 = { componentDidMount: function() { console.log('Mixin1.componentDidMount()'); } }; var Mixin2 = { componentDidMount: function() { console.log('Mixin2.componentDidMount()'); } }; var MyComponent = React.createClass({ mixins: [Mixin1, Mixin2], render: function() { return <div>hello world</div>; } }); ``` When `MyComponent` is mounted into the page, the following text will print to the console: ``` Mixin1.componentDidMount() Mixin2.componentDidMount() ``` ## When should you use mixins? In general, add a mixin whenever you want a component to share some utility methods, public interface, or lifecycle behavior. Often it's appropriate to use them as you would use a superclass in another OOP language. </ins>

Discussion:
There was another issue tracking this , but it looks like it got merged into an issue that was already closed so it never got fixed.
There's also .
SVG images are an important part of my current project - is there anything I could do to help push this issue through?
is a newer PR without the merge conflicts of
Closed with
Change:
var React = require('React'); var ReactMount = require('ReactMount'); var ReactTestUtils = require('ReactTestUtils'); <del> var WebComponents = undefined; </del> <ins> var WebComponents = WebComponents; </ins> try { <del> WebComponents = require('WebComponents'); </del> <ins> if (WebComponents === undefined && jest !== undefined) { WebComponents = require('WebComponents'); } </ins> } catch(e) { <del> /* leave WebComponents undefined */ </del> <ins> // Parse error expected on engines that don't support setters // or otherwise aren't supportable by the polyfill. // Leave WebComponents undefined. </ins> } describe('constructAndRenderComponentByID', function() {

Discussion:
Our tests currently only pass in the browser when running in Chrome. This is because it supports WebComponents already. However they fail in every other browser. I think this is because of when is actually loaded. It's currently getting packaged into react-test because we're requiring it. It creates a new which is resulting in nodes we create with to have a different prototype than what is expected in WebComponents. WebComponents's new Node prototype has a different implementation of which does an check which our nodes are failing. I think if we loaded into the browser before we loaded JS, the node we create for markup wrapping would have the right prototype.
Change:
"lint-build": "node ./scripts/rollup/validate/index.js", "extract-errors": "yarn build --type=dev --extract-errors", "postinstall": "node node_modules/fbjs-scripts/node/check-dev-engines.js package.json && node ./scripts/flow/createFlowConfigs.js && node ./scripts/yarn/downloadReactIsForPrettyFormat.js", <del> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source.js --runInBand", </del> <ins> "debug-test": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.source.js --runInBand", </ins> "test": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source.js", "test-persistent": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.source-persistent.js", <del> "debug-test-persistent": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.source-persistent.js --runInBand", </del> <ins> "debug-test-persistent": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.source-persistent.js --runInBand", </ins> "test-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.source.js", "test-prod-build": "yarn test-build-prod", "test-build": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.build.js", "test-build-prod": "cross-env NODE_ENV=production jest --config ./scripts/jest/config.build.js", "test-build-devtools": "cross-env NODE_ENV=development jest --config ./scripts/jest/config.build-devtools.js", <del> "debug-test-build-devtools": "cross-env NODE_ENV=development node --inspect-brk node_modules/.bin/jest --config ./scripts/jest/config.build-devtools.js", </del> <ins> "debug-test-build-devtools": "cross-env NODE_ENV=development node --inspect-brk node_modules/jest/bin/jest.js --config ./scripts/jest/config.build-devtools.js", </ins> "test-dom-fixture": "cd fixtures/dom && yarn && yarn prestart && yarn test", "flow": "node ./scripts/tasks/flow.js", "flow-ci": "node ./scripts/tasks/flow-ci.js",

Discussion:
<!-- 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? Throw exception, don't run tests. SyntaxError: missing ) after argument list 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: one of the commands: yarn debug-test yarn debug-test-persistent yarn debug-test-build-devtools chrome://inspect and press “Inspect”. What is the expected behavior? Possibility debug tests. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.2.0 and higher. Chrome 77.0.3865.120 Windows 10. Older version React hasn't this feature.
fixed in
Change:
// tell the service worker which versions of backends are needed for the current page function updateRequiredBackends() { <ins> if (requiredBackends.size === 0) { return; } </ins> window.postMessage( { source: 'react-devtools-backend-manager',

Discussion:
the codepen linked above. sure to open the Debug View, so codepen doesn't add any additional iframes (). : Warning in the Console tab: . Error in the Components tab: . After dismissing the error, all components seem to be accounted for (you might need to adjust the "Hide components where..." option). In my actual application the error pops up for every change in the tree, making the devtools virtually unusable. Note: This only seems to happen if the iframe is some time after the initial React tree was mounted in the parent window. When I remove the so the iframe is synchronously, I no longer see any warnings. Related issues: Every time No response 27.7 (5/7/2023) in Google Chrome Version 112.0.5615.165 (Official Build) (64-bit) Cannot add node "3" because a node with that id is already in the Store. No response No response
Hey thanks for reporting this. Can confirm this issue, but I am getting different error on my side and only when refreshing the page. Extension works as expected for me when I open the page for the first time. I will put up a fix for this.
can you please also validate this on your side? You can download a build from our CircleCI pipeline here - Chrome extension should be in archive, you can then install it via dialog in
Yes! I'm no longer seeing the warning/errors when I use the build you linked. Thanks for the fix :)
Great, thanks for helping resolving this. This will be included in v4.27.8 release, which I will publish this week.
Change:
"bin": { "react-devtools": "./bin.js" }, <del> "files": [], </del> <ins> "files": [ "bin.js", "app.html", "app.js", "index.js", "icons" ], </ins> "scripts": { "start": "node bin.js" },

Discussion:
react-devtools version: 4.22.0 npm -g install react-devtools react-devtools
This was broken because of . My apologies.
Fix has been published as 4.22.1. Sorry again.
react-devtools: 4.22.1 <img width="417" alt="Screen Shot 2021-12-15 at 1 09 33 PM" src="https://user-"react-devtools: 4.21 has no problem.
Thanks for confirming,
Change:
let currentEventTime: number = NoTimestamp; let currentEventTransitionLane: Lanes = NoLanes; <ins> let isRunningInsertionEffect = false; </ins> export function getWorkInProgressRoot(): FiberRoot | null { return workInProgressRoot; }

Discussion:
Following up on (/cc ) React version: 18.0.0-rc.3-next-- an update (e.g. ) from within Link to code example: Update is applied and no warning is issued. According to cannot schedule updates. But seems to "work". Maybe this is just incidental because it's the first render? I got the impression that this should definitely cause a warning (not implemented) but I wonder if we also should consistently drop updates from ?
Change:
1. Assign a `ref` attribute to anything returned from `render` such as: <del> ```html <input ref="myInput" /> ``` </del> <ins> ```html <input ref="myInput" /> ``` </ins> 2. In some other code (typically event handler code), access the **backing instance** via `this.refs` as in: <del> ```javascript this.refs.myInput ``` </del> <ins> ```javascript this.refs.myInput ``` </ins> You can access the component's DOM node directly by calling `React.findDOMNode(this.refs.myInput)`.

Discussion:
I'm trying to use the attribute as described here: Unfortunately, sometimes returns , when is called multiple times. MWE:
This is intended – when the component is unmounted or the ref changes, the old ref gets called with null before it's called with the new value (or the same component instance again). If you store the instance on your component, this effect should be unobservable as long as your component is mounted, but it prevents memory leaks. If you want to do something with in the ref handler, you should check if it's null.
Thanks for the information! I think this might be worth mentioning in the docs.
Change:
React = require('React'); ReactDOM = require('ReactDOM'); ReactTestUtils = require('ReactTestUtils'); <ins> // NOTE: We're explicitly not using JSX here. This is intended to test // classic JS without JSX. </ins> ComponentClass = React.createClass({ render: function() { return React.createElement('div');

Discussion:
The have this at the beginning: But there're a number of instances of JSX in the file. For example, . the note be removed or clarified? JSX be purged from the file? adding tests to this file should they be free of JSX? In certain contexts but not others?
Normally, our style is to use jsx within tests. I think some of the tests explicitly aren't using jsx, and that's the point. Perhaps it would be better to copy-paste that message into each of the tests that doesn't use jsx, since it's easy to miss the note up at the top and having the note at the top is somewhat ambiguous.
Thanks for the feedback. Yeah, for both of those reasons I'd say :+1: to either that or splitting it into two files if that made sense to you (would help with the ease of missing it if it's just at the top and make the alternative of repeating it within the file unnecessary): .
I'd be happy to submit a PR for either of these cases!
I think I prefer having the inline comment copy-pasted. A little copy-pasting never hurt anyone (). I'd take a PR for this, assuming no one else objects.
Change:
ReactDOM = require('react-dom'); ReactTestUtils = require('react-dom/test-utils'); <ins> class ClassComponent extends React.Component { render() { return null; } } </ins> TestComponent = class extends React.Component { render() { <del> return ( <div> {this.props.destroy ? null : ( <div ref="theInnerDiv">Lets try to destroy this.</div> )} </div> ); </del> <ins> if (this.props.destroy) { return <div />; } else if (this.props.removeRef) { return ( <div> <div /> <ClassComponent /> </div> ); } else { return ( <div> <div ref="theInnerDiv" /> <ClassComponent ref="theInnerClassComponent" /> </div> ); } </ins> } }; });

Discussion:
Do you want to request a feature or report a bug? Bug What is the current behavior? If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does not call the original ref with null. Note that it doesn't call ref1 (passed to FooInner as ref) with null Note that it does call ref1 (passed to div as ref) with null If you modify the ref from either a HostComponent or a ClassComponent (change from to ), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance. (take the sandboxes above and change the second to What is the expected behavior? Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, as long as . For ClassComponents, as long as -- which means if is null, the behavior is different (hence this issue). We should probably pick one and make it consistent. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.
Change:
// 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,

Discussion:
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.
Change:
</React.Profiler> </AdvanceTime> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);

Discussion:
: However, given: I'm getting a log when I click on the unprofiled counter. Reproduction: Am I misunderstanding this API, or is this a bug?
As the state is being updated by Counter function which is being called on both the profiled and unprofiled counter, is causing re render and is being called both the times.
Thanks but I'm pretty sure that the way it's documented (and what would be sensible) it shouldn't be operating like that. Also, I tried making a separate component instead of using the same one and I got the same result.
At a quick glance it does look unexpected. Don't have time to dig in further at the moment though.
It seems that this occurs for elements which have same type with greater or equal depth in same tree. See:
I don't think it has anything to do with the element type, but where they are declared relative to where the tags are defined. It looks like for a subtree that belongs to a single owner- rendering further down in the subtree will cause the Profiler higher up to call . Given the above example:
This does not look to be hooks-specific, nor is it a recent regression. (Same behavior is exhibited for class components in the earliest release of the Profiler component- v16.5.)
It seems that the is always marked as in phase.
Thanks