jiebi/CodeConvo huggingface dataset:
Code change:
I’ve seen the “rendered fewer hooks than expected” invariant a couple times now pointing at a component rendered as a part of an error boundary that just caught an error when that component does not use hooks at all. I’ve been able to fix this issue by un-commenting: I haven’t been able to produce a minimal test-case yet . I’m reporting anyway with the temporary fix that worked for me in case you have any insight on what a minimal test-case could be. I’ll update this issue if I keep running into the problem and I can create a minimal test-case.
I ran into the issue again and was able to produce a small repro: Pressing the “throw” button results in the invariant: With a component stack of: Which is weird since has no hooks!
Wanna look into fixing? Should be easy — there must be a missing call somewhere. Or maybe doesn't reset everything we need.
I looked into it, wrote a test, and discovered it’s fixed on master The test is broken on 16.8.6, I didn’t bother bisecting to find the commit that fixed it. PR for the test: .
I thought I was seeing this in 16.9, but it turns out we were on and , and both need to be updated for this to work.

Related discussion:
text: Scheduler.flushAll(); expect(root).toMatchRenderedOutput('hello'); }); <ins> // Regression test for https://github.com/facebook/react/issues/15732 it('resets hooks when an error is thrown in the middle of a list of hooks', async () => { const {useEffect, useState} = React; class ErrorBoundary extends React.Component { state = {hasError: false}; static getDerivedStateFromError() { return {hasError: true}; } render() { return ( <Wrapper> {this.state.hasError ? 'Error!' : this.props.children} </Wrapper> ); } } function Wrapper({children}) { return children; } let setShouldThrow; function Thrower() { const [shouldThrow, _setShouldThrow] = useState(false); setShouldThrow = _setShouldThrow; if (shouldThrow) { throw new Error('Throw!'); } useEffect(() => {}, []); return 'Throw!'; } const root = ReactTestRenderer.create( <ErrorBoundary> <Thrower /> </ErrorBoundary>, ); expect(root).toMatchRenderedOutput('Throw!'); act(() => setShouldThrow(true)); expect(root).toMatchRenderedOutput('Error!'); }); </ins> });
Code change:
: 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

Related discussion:
text: } case Profiler: if (enableProfilerTimer) { <del> workInProgress.effectTag |= Update; </del> <ins> // Profiler should only call onRender when one of its descendants actually rendered. const hasChildWork = workInProgress.childExpirationTime >= renderExpirationTime; if (hasChildWork) { workInProgress.effectTag |= Update; } </ins> } break; case SuspenseComponent: {
Code change:
: 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

Related discussion:
text: Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <React.Profiler id="parent" onRender={callback}> <AdvanceTime byAmount={10}> <React.Profiler id="child" onRender={callback}>
Code change:
: 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

Related discussion:
text: </React.Profiler> </AdvanceTime> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);
Code change:
: 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

Related discussion:
text: Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <React.Profiler id="first" onRender={callback}> <AdvanceTime byAmount={20} /> </React.Profiler> <React.Profiler id="second" onRender={callback}> <AdvanceTime byAmount={5} /> </React.Profiler> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(2);
Code change:
: 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

Related discussion:
text: Scheduler.unstable_advanceTime(5); // 0 -> 5 ReactTestRenderer.create( <del> <> </del> <ins> <React.Fragment> </ins> <AdvanceTime byAmount={20} /> <React.Profiler id="test" onRender={callback}> <AdvanceTime byAmount={5} /> </React.Profiler> <AdvanceTime byAmount={20} /> <del> </>, </del> <ins> </React.Fragment>, </ins> ); expect(callback).toHaveBeenCalledTimes(1);
Code change:
: 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

Related discussion:
text: } } <del> class Pure extends React.PureComponent { render() { return this.props.children; } } </del> const renderer = ReactTestRenderer.create( <React.Profiler id="outer" onRender={callback}> <Updater> <del> <React.Profiler id="middle" onRender={callback}> <Pure> <React.Profiler id="inner" onRender={callback}> <div /> </React.Profiler> </Pure> </del> <ins> <React.Profiler id="inner" onRender={callback}> <div /> </ins> </React.Profiler> </Updater> </React.Profiler>, ); // All profile callbacks are called for initial render <del> expect(callback).toHaveBeenCalledTimes(3); </del> <ins> expect(callback).toHaveBeenCalledTimes(2); </ins> callback.mockReset();
Code change:
: 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

Related discussion:
text: }); }); <del> // Only call profile updates for paths that have re-rendered // Since "inner" is beneath a pure component, it isn't called expect(callback).toHaveBeenCalledTimes(2); expect(callback.mock.calls[0][0]).toBe('middle'); expect(callback.mock.calls[1][0]).toBe('outer'); </del> <ins> // Only call onRender for paths that have re-rendered. // Since the Updater's props didn't change, // React does not re-render its children. expect(callback).toHaveBeenCalledTimes(1); expect(callback.mock.calls[0][0]).toBe('outer'); </ins> }); it('decreases actual time but not base time when sCU prevents an update', () => {
Code change:
: 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

Related discussion:
text: render() { instance = this; return ( <del> <> </del> <ins> <React.Fragment> </ins> <Yield value="first" /> {this.state.count} <Yield value="last" /> <del> </> </del> <ins> </React.Fragment> </ins> ); } }
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 (__DEV__) { const inst = workInProgress.stateNode; <del> if (inst.props !== nextProps) { </del> <ins> if (shouldUpdate && inst.props !== nextProps) { </ins> if (!didWarnAboutReassigningProps) { console.error( 'It looks like %s is reassigning its own `this.props` while rendering. ' +
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: cloneUpdateQueue(current, workInProgress); <del> const oldProps = workInProgress.memoizedProps; instance.props = </del> <ins> const unresolvedOldProps = workInProgress.memoizedProps; const oldProps = </ins> workInProgress.type === workInProgress.elementType <del> ? oldProps : resolveDefaultProps(workInProgress.type, oldProps); </del> <ins> ? unresolvedOldProps : resolveDefaultProps(workInProgress.type, unresolvedOldProps); instance.props = oldProps; const unresolvedNewProps = workInProgress.pendingProps; </ins> const oldContext = instance.context; const contextType = ctor.contextType;
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: (typeof instance.UNSAFE_componentWillReceiveProps === 'function' || typeof instance.componentWillReceiveProps === 'function') ) { <del> if (oldProps !== newProps || oldContext !== nextContext) { </del> <ins> if ( unresolvedOldProps !== unresolvedNewProps || oldContext !== nextContext ) { </ins> callComponentWillReceiveProps( workInProgress, instance,
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: newState = workInProgress.memoizedState; if ( <del> oldProps === newProps && </del> <ins> unresolvedOldProps === unresolvedNewProps && </ins> oldState === newState && !hasContextChanged() && !checkHasForceUpdateAfterProcessing()
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: // 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;