jiebi/CodeConvo huggingface dataset:
Change:
isEffect, ); return; // Handled <ins> case 'TSAsExpression': visitFunctionWithDependencies( callback.expression, declaredDependenciesNode, reactiveHook, reactiveHookName, isEffect, ); return; // Handled </ins> case 'Identifier': if (!declaredDependenciesNode) { // No deps, no problems.

Discussion:
React version: 17.0.1 Setup eslint with as parser Cast a function passed to Link to code example: The following error was reported The rule should interpret the function argument correctly and know that it is already inline.
It looks like it is something that would be easy to support, but the question is: why would you do that?
Heh, a fair question. In my case, I needed it in order to support generics for a hook that helps manage state for asynchronous calls like mutations: Without the cast, TS doesn't know that the shape of the args object is the same. On the return statement, TS warns: This remains true even if I make the args a generic type too, so I think the issue is unavoidable.
TS is correct there. A function that has the same input type & return type as is not assignable to . might have other properties attached to it as well, which won't be attached to . For your particular situation, the type for can be a function that has the same argument & return types as , but should not be . Casting it as is lying to typescript.
Ahhh. Thanks With that hint I was able to fix my types and obviate the cast. That said, I would recommend keeping this issue open, since there will always be cases where folks will have to resort to casts like these, whether due to limitations in TS's expressiveness or (as in this case and I suspect most cases) one's ability to understand the type complexities and specify the types correctly. Sadly, not everyone has access to a to help them out when the types get complex.
Change:
// autoFocus is polyfilled/normalized by AutoFocusMixin // autoFocus: HAS_BOOLEAN_VALUE, autoPlay: HAS_BOOLEAN_VALUE, <ins> capture: MUST_USE_ATTRIBUTE | HAS_BOOLEAN_VALUE, </ins> cellPadding: null, cellSpacing: null, charSet: MUST_USE_ATTRIBUTE,

Discussion:
Consider following snippet: Expected DOM Current behaviour Demo: W3C Specs:
I made a pull request, but was a bit faster. The pull requests are different, so maybe it is good that there are two. :smile:
That's wonderful, Thx!
Change:
--dark-color-expand-collapse-toggle: #8f949d; --dark-color-link: #61dafb; --dark-color-modal-background: rgba(0, 0, 0, 0.75); <ins> --dark-color-primitive-hook-badge-background: rgba(0, 0, 0, 0.25); --dark-color-primitive-hook-badge-text: rgba(255, 255, 255, 0.7); </ins> --dark-color-record-active: #fc3a4b; --dark-color-record-hover: #a2e9fc; --dark-color-record-inactive: #61dafb;

Discussion:
I mostly use the "dark" theme which these badges looked good in. The "light" theme is broken though. No contrast.
Change:
`), ).toMatchSnapshot(); }); <ins> it('uses custom identifiers for $RefreshReg$ and $RefreshSig$', () => { expect( transform( `export default function Bar () { useContext(X) return <Foo /> };`, { freshOptions: { refreshReg: 'import.meta.refreshReg', refreshSig: 'import.meta.refreshSig', }, }, ), ).toMatchSnapshot(); }); </ins> });

Discussion:
Do you want to request a feature or report a bug? Feature Right now babel plugin emits globals: It would be nice to have them configurable. That would allow to use in environments like SystemJS and have simpler implementation: If you don't mind I could create PR with changes to react-refresh/babel next week. environment:
Happy to take a PR.
Change:
); props.defaultValue = null; <del> props.value = value != null ? value : this.state.value; </del> <ins> props.value = null; </ins> props.onChange = this._handleChange; // Always set children to the same thing. In IE9, the selection range will

Discussion:
creates invalid html markup and appears to be unnecessary for proper functionality of the . Admittedly my test here was very minimal, but removing from the object using rendered valid html and the component still worked properly in the browser and passed all it's tests. Other than perhaps supporting server-side rendering, is there a purpose to rendering into the real dom?
Good catch :+1: The reason is set is because is , i.e, it's treated as a property rather than an attribute at run-time (which is correct). But like you say, it should not generate markup for the attribute (because it's wrong). I'm not 100% sure what the preferred fix is here, add another "directive" ex: ?
I don't think it's invalid markup. just isn't used (unless you use , which we don't do for ). I was surprised that just deleting value would work, but I guess we're applying updates to value of the actual node manually, not relying on render. This seems like a good enough approach to me. We already render the initial value as a text child so we don't use this for server rendering. another directive could make sense if we get scoped properties in there since this is only true for <textareabut not for other inputs. But until then... Want to submit a PR (cc
By invalid I meant the generated markup will not validate via the W3C html validator, throwing the error "Attribute value not allowed on element textarea at this point." Yes, I will submit a PR.
Change:
'release:setup', 'clean', 'build', <del> 'gem-react-source:release', 'gem-react-source:pack', </del> 'release:bower', 'release:starter', 'compress',

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:
{ "private": true, "name": "react-devtools-timeline", <del> "version": "5.3.1", </del> <ins> "version": "6.0.0", </ins> "license": "MIT", "dependencies": { "@elg/speedscope": "1.9.0-a6f84db",

Discussion:
development website Uncaught Error: getCommitTree(): Invalid commit "1" for root "1". There are only "1" commits. Every time react-devtools-extensions 1- getCommitTree(): Invalid commit "2" for root "1". There are only "1" commits.
Hi thank you for reporting. should fix this. It's scheduled to be included in DevTools 6.0.0. Let us know if it's still happening in 6.0.0
Change:
} }); <ins> it('should allow extension of native prototypes', function() { /*eslint-disable no-extend-native */ String.prototype.key = 'react'; Number.prototype.key = 'rocks'; /*eslint-enable no-extend-native */ var instance = ( <div> {'a'} {13} </div> ); var traverseFn = jasmine.createSpy(); traverseAllChildren(instance.props.children, traverseFn, null); expect(traverseFn.calls.length).toBe(2); expect(traverseFn).toHaveBeenCalledWith( null, 'a', '.0' ); expect(traverseFn).toHaveBeenCalledWith( null, 13, '.1' ); delete String.prototype.key; delete Number.prototype.key; }); </ins> it('should throw on object', function() { expect(function() { traverseAllChildren({a: 1, b: 2}, function() {}, null);

Discussion:
I came across this one because I'd extended with a custom key generator. React ends up treating the function itself as the child key, so it hides any strings that come after it. Object key handling is documented and makes sense. Not sure it makes sense to handle string keys this way.
what do you want to do here?
I think the issue is actually here yeah? Should probably be changed to
Nice catch. I think that we might actually have more of these flaws. We should be more careful as this prevents browsers to add to the string prototype. that if branch can be separated and we just use the implicit key for string/number.
Change:
title: Web Components - id: glossary title: React (Virtual) DOM Terminology <del> - title: Flux items: - id: flux-overview title: Flux Overview href: https://facebook.github.io/flux/docs/overview.html - id: flux-todo-list title: Flux TodoMVC Tutorial href: https://facebook.github.io/flux/docs/todo-list.html </del>

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: A slow loading script does not seem to cause React to suspend as expected from this description. a with a deliberate delay on the response that React canary does not suspend while the script is loading <!-- 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: --This example contains a script where the server takes six seconds to respond. It changes the text to once executed. Note that it immediately displays . I expect it to display the Suspense fallback message for six seconds before switching to around the same time that the switch is made.
I have the same problem with . suspense does not fallback
Thank you for raising this. This was actually an oversight when writing the documention. Script tags don't suspend since they're not blocking rendering HTML unlike CSS. We're just removing any mention of Suspense from this page:
Change:
```javascript{3-5} render: function() { return ( <del> <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}> </del> <ins> <ReactCSSTransitionGroup transitionName="example" transitionAppear={true} transitionAppearTimeout={500}> </ins> <h1>Fading at Initial Mount</h1> </ReactCSSTransitionGroup> );

Discussion:
When a is used without timeout props, it : for each missing timeout prop. However, that URL simply points to . The code listed there does use timeout props, but nothing on the page explains what those props do or why they're necessary. In fact, the word "timeout" only appears in the names of those props in code examples. Could we get some explanation in the docs, please?
Hmm, I think it does: <img width="516" alt="screen shot 2016-07-20 at 15 23 18" src=""Some line breaks would help there. There is an entry explaining why they were in 0.14 release notes: <img width="717" alt="screen shot 2016-07-20 at 15 24 12" src=""(I’m not saying it’s easy to find—it’s out fault for not updating the docs to reflect that.) Would you like to massage the doc page and send a PR?
Ah, got it. Yeah, knowing how it works now, I can do that. Thanks!
Can transitionAppearTimeout replace transitionLeaveTimeout?? If i am using animation for initial mount because i am still getting error with .... In facebook docs they replaced LeaveTimetout with AppearTimeout... but it looks like there still must be LeaveTimeout..
Change:
<script type="text/javascript" src="//use.typekit.net/vqa1hcx.js"></script> <script type="text/javascript">try{Typekit.load();}catch(e){}</script> <ins> <!--[if lte IE 8]> <script type="text/javascript" src="/react/js/es5-shim.js"></script> <script type="text/javascript" src="/react/js/es5-sham.js"></script> <![endif]--> </ins> <script type="text/javascript" src="/react/js/codemirror.js"></script> <script type="text/javascript" src="/react/js/javascript.js"></script> <script type="text/javascript" src="/react/js/react.min.js"></script>

Discussion:
Should be as simple as making sure we include the polyfills we document
Somehow I assumed it was intentional that the polyfills weren't included, now I feel silly.
Eh, not really intentional, just never bothered to do it. Looking back it's a bit silly for us to say that we work in IE8 but not prove it.
It's ok guys, don't blame yourself for that IE8 story :) (this post is related to : !topic/reactjs/Z2jNf7za7cM) Meanwhile, I've just replied to Paul. Maybe you can help there because I'm stuck :+1: Thanks for your support and the work you've accomplished.
Hmm, it would appear this won't be possible so long as we use JSXTransform on the site. We could fix the NodeList -array issue, but we won't (and shouldn't try to) make changes to esprima to make it work (I think it's mostly using "reserved" words as keys. I guess we can turn this bug into "include polyfills, make sure things works as well as possible, provide some warnings if using IE8 about the problem"
So basically (tell me if I'm wrong) JSXTransform is not compatible with IE8.0 ? But ReactJS should be compatible, right ?
Correct. I just tested this myself with the zip I emailed to you - it's online for now at
Thanks zpao (you can remove it from your server if you wish I downloaded the srcs). I would recommend to add the non JSXTransformed example to git or the tutorial maybe ? Again thanks Paul and Spicyj for you help.
This should be easy now that has landed.
8 is out with , so this should be even easier to jump into.
Change:
ReactTestUtils.renderIntoDocument(<select value={null}><option value="test"/></select>); expect(console.error.argsForCall.length).toBe(1); }); <ins> it('should refresh state on change', function() { var stub = <select value="giraffe" onChange={noop}> <option value="monkey">A monkey!</option> <option value="giraffe">A giraffe!</option> <option value="gorilla">A gorilla!</option> </select>; stub = ReactTestUtils.renderIntoDocument(stub); var node = ReactDOM.findDOMNode(stub); ReactTestUtils.Simulate.change(node); expect(node.value).toBe('giraffe'); }); </ins> });

Discussion:
Case: ,js,output I have a with a value depending on the state. When I select the 'baz' item in the combobox, and don't do anything in the onChange handler, the combobox suddenly displays the first element (even though the state is still the same). So, the state of the combobox is inconsistent with the state of its 'value' property. This seems to happen in at least Chrome and Safari.
Change:
var SyntheticEvent = require('SyntheticEvent'); var assign = require('Object.assign'); <ins> var emptyObject = require('emptyObject'); </ins> var findDOMNode = require('findDOMNode'); var topLevelTypes = EventConstants.topLevelTypes;

Discussion:
I am trying to render a component using the preliminary shadow renderer support in TestUtils. A simple reproducible test case of my issue is this When I run this in my Jest test, I get: It looks like this error is thrown whenever the component being rendered has . I thought perhaps the context was required (although I haven't had any problems omitting it in my actual app), but even when using I get the same exception.
I think this is a known issue with shallow rendering. cc
thanks for the report. Context isn't meant to be supported with shallow rendering (i.e., we haven't tested it), but it looks like you may be able to work around this problem by passing an object as the second argument to : it looks like an additional argument was to the shallow rendering API in . What was the thinking here? Can we default this to an empty object?
Thanks, the workaround works great. And I see you posted a fix as well so looking forward to that.
Change:
- [`createFragment`](create-fragment.html), to create a set of externally-keyed children. - [`update`](update.html), a helper function that makes dealing with immutable data in JavaScript easier. - [`PureRenderMixin`](pure-render-mixin.html), a performance booster under certain situations. <del> - (DEPRECATED) [`classSet`](class-name-manipulation.html), for manipulating the DOM `class` string a bit more cleanly. </del> The add-ons below are in the development (unminified) version of React only:

Discussion:
Now that we deprecated it, we should remove it before we ship 0.14. Would you like the honors
Change:
return { "debug": true, "mocking": true, <ins> "commonerConfig": grunt.config.data.pkg.commonerConfig, </ins> "constants": { "__VERSION__": grunt.config.data.pkg.version, "__DEV__": true

Discussion:
I'd rather do it , if you don't mind.
I think we should do both. I think a forced clean should force clean all of the build artifacts (of which .module-cache is a part of).
can we distinguish between and ?
In what situation would you want to clean but not remove ?
I'm actually not aware of any other use cases for so maybe this is fine. But it still means we need to tell people to do if they encounter problems that might be fixed by doing so, whereas gives us a way to get the same effect with no verbal communication.
I'm going to do it. I think we should probably also do .
Closed by .
Change:
var instantiateReactComponent = require('instantiateReactComponent'); var invariant = require('invariant'); var keyMirror = require('keyMirror'); <ins> var keyOf = require('keyOf'); </ins> var merge = require('merge'); var mixInto = require('mixInto'); var monitorCodeUse = require('monitorCodeUse');

Discussion:
Right now we don't do this consistently, so you could have behavior that varies depending on where you put the key in your class spec. That's not great. Here's an example: (using master) This outputs: I think we should consistently behave like CompB (component, then mixin methods) but disagrees. Any other opinions. Potentially interested (once we figure out which way we go)? This is relatively contained and testable but it does take you right into core.
Doing mixins first is more intuitive to me because that's normally how people write the specs (in my experience, at least).
Hi, thanks for the mention. I'd like to take on this if nobody minds. I agree with that calling mixins first is more intuitive.
Go for it! Let me know if you have any questions; I'm happy to help.
OK great. I'll try to do it tomorrow.
Mention me if there's something else I can take. I liked that although this task had a small scope, it introduced me to the way actually works and how spec transforms into a component instance. It would be cool if I could take a few small tasks in other areas (rendering, batching) that introduce me to these areas.
Change:
const requiredBackends = new Set<string>(); <del> function registerRenderer(renderer: ReactRenderer) { </del> <ins> function registerRenderer(renderer: ReactRenderer, hook: DevToolsHook) { </ins> let version = renderer.reconcilerVersion || renderer.version; if (!hasAssignedBackend(version)) { version = COMPACT_VERSION_NAME; } <del> requiredBackends.add(version); </del> <ins> // Check if required backend is already activated, no need to require again if (!hook.backends.has(version)) { requiredBackends.add(version); } </ins> } function activateBackend(version: string, hook: DevToolsHook) {

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:
expect(childEnterCalls).toBe(1); expect(parentEnterCalls).toBe(0); }); <ins> // Test for https://github.com/facebook/react/issues/16763. it('should call mouseEnter once from sibling rendered inside a rendered component', done => { const mockFn = jest.fn(); class Parent extends React.Component { constructor(props) { super(props); this.parentEl = React.createRef(); } componentDidMount() { ReactDOM.render(<MouseEnterDetect />, this.parentEl.current); } render() { return <div ref={this.parentEl} />; } } class MouseEnterDetect extends React.Component { constructor(props) { super(props); this.firstEl = React.createRef(); this.siblingEl = React.createRef(); } componentDidMount() { this.siblingEl.current.dispatchEvent( new MouseEvent('mouseout', { bubbles: true, cancelable: true, relatedTarget: this.firstEl.current, }), ); expect(mockFn.mock.calls.length).toBe(1); done(); } render() { return ( <React.Fragment> <div ref={this.firstEl} onMouseEnter={mockFn} /> <div ref={this.siblingEl} /> </React.Fragment> ); } } ReactDOM.render(<Parent />, container); }); </ins> });

Discussion:
Do you want to request a feature or report a bug? I want to report a bug. What is the current behavior? Event handlers on elements are fired twice, when hovering from one element onto the next. 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? Event handlers should only fire once. Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React 16.8.4 ReactDOM 16.8.4 Chrome 76.0.3809.132 Firefox 69.0 (64-Bit) Edge 44..267.0
After testing it again and again, I found how to reproduce it: Step 1, render a new component inside a rendered component; Step 2, inside the new component, mouse enter a node from its sibling. Current result: onMouseEnter is called more than once. Demo: We may change the issue title because it's not related with . I've made a test and fixture for this: Hope the information can be helpful. I still have no idea how to fix it. If there's no one working on this, I would like to pick this up. There's a similar issue Do you have any advice?
Go for it,
Let's close this? I see the fix was merged in .