bailout when hook throws an error#2193
Conversation
|
No, those are part of the diffing algorithm it are only the ones scheduled for delayed execution that bypass diff and don't get picked up by the parentComponents. Seems like I didn't press enter when commenting on your issue, sorry for that. |
|
ahh. if you get a chance can you link to where that happens? |
|
I can surely do so For the first case we do a synchronous cleanup for the effects still pending for a component this can happen with many subsequent renders, here we use the _render option this is within the diffing loop so if a throw occurs it will catch it just as a normal throw in render would. For the next case we have |
|
ah ok, so then |
robertknight
left a comment
There was a problem hiding this comment.
Looks good, except that exceptions in the effect invocations in the _render and _commit options hooks defined in hooks/src/index.js are not caught. If you wanted to handle the latter case in a separate PR, since it refers to the useLayoutEffect hook, I'd be fine with that.
|
One last scenario is throwing in This PR: #2203 can solve that more easily |
|
@robertknight with the new changes in this PR errors in it('works with closure effect callbacks capturing props', () => {
const values = [];
function Comp(props) {
useEffect(() => values.push(props.value));
return null;
}
render(<Comp value={1} />, scratch);
render(<Comp value={2} />, scratch);
return scheduleEffectAssert(() => expect(values).to.deep.equal([1, 2]));
); |
4e6a9d6 to
e3ca2f9
Compare
* bailout when hook throws an error * solve more scenario's * solve issue with double commit * clean solution for effect-error bailing * better solution where everything is handled in options._commit * add accidentely removed whitespace * add ._render test
fixes: #2192