I'm going to keep this relatively high level as I can't seem to re-create it in the demo app... But I'm having the weirdest problem in React Native on iOS.
When there is an error thrown during the execution of the React Native code in dev mode, it is caught by a random catch() block from an old fetch request that completed in the past. This fetch block has a .done() and terminates.
This then causes a very weird series of errors:
1st: ExceptionsManager.js:70 Warning: There is an internal error in the React performance measurement code. Did not expect componentDidUpdate timer to start while render timer is still in progress for another instance.
2nd: ExceptionsManager.js:55 Cannot read property 'getHostNode' of null
3rd: ExceptionsManager.js:70 Unhandled JS Exception: Cannot read property 'getHostNode' of null
Related
I am currently learning React from book React and React Native 4th Edition.
In that I have doubt in topic Cancelling requests and resetting state.
It says
There's a good chance that, at some point, your users will navigate your app and cause
components to unmount before responses to their API requests arrive. When this
happens, an error occurs because the component will attempt to update the state values of
a component that has been removed.Thankfully, the useEffect() Hook has a mechanism to clean up things such as
pending API requests when the component is removed.Let's take a look at an example of
this in action:
This is the Example.
I just commented promise.cancel() as said to do in book (to see error).But i am not getting error?
You are using react 18 whitch has Improved memory usage now cleans up more internal fields on unmount, making the impact from unfixed memory leaks
After migration from react v16 to react v18, when any error occurs in dev or testing environment, there is error UI overlay occurs, covering DOM elements. That's why cypress cannot continue testing. The thing is, that these errors do not affect how UI works.
For instance, Firebase library sometimes gives an error and the UI error overlay comes in, but in React v16, you could completely ignore this error and continue testing or using the app as you want, cause Firebase functionality is not crucial there. But in React v18 it shows that overlay, even though the UI is completely stable under the overlay.
Here is the screenshot of the overlay, but with another error. I could not reproduce Firebase error now, cause it happens randomly:
UI error
Could you please suggest something to resolve this problem, cause there are almost 300 test cases in that project. It takes a lot of time to run all the tests completely and this overlay can break all the tests after, for example 30 minutes, when half of the tests are done.
I'm writing custom data provider. If I throw an error from data source method, e.g. delete('resource', options) I see error properly logged (react-admin uses showNotification for that internally) and immediately react death screen Unhandled Rejection (Error), and the question is how to stop react-admin throwing unhandled rejections ? Maybe there are some global error handler, because I must throw, because error goes to authentication provider's checkError method, and if I throw react-admin shows it's message properly, so seems like it's expected behavior for react admin.
What I need to do to fix this react death screen?
P.S. I'm returning promises from data sources and auth providers, react error boundaries doesn't handle async code
P.P.S. please do not suggest fix error which causes it, read article above, it should be thrown
I've been experimenting with components that do a react-cache style thing and do web service calls right in the render method, throwing a promise up to a React.Suspense component and re-rendering when the data is there. They call a web service, check the response, and either render or throw an error up to an error boundary depending on the response. I've noticed that whenever an error is thrown in a component, it renders twice. The first time the callstack looks normal, and the second time the callstack includes calls to invokeGuardedCallbackDev and invokeGuardedCallback, which seem to have something to do with React ensuring that errors appear in the console even when "caught" by an error boundary in a dev build.
I can reproduce this with react and react-dom 16.8.6 by just rendering a component like this: https://codesandbox.io/s/components-that-throw-render-twice-i26qc.
I'm wondering why this happens, because it's causing the components to re-fetch data from the web service, re-throw another promise, and results in an "Uncaught Promise" error appearing in the console.
This seems to be caused by a recent change in react/react-dom. If you revert both to version 16.0.0, you will see that it only renders the component once. See: https://codesandbox.io/s/components-that-throw-render-twice-03fdb
Looking at the version history, there seem to be a couple of bugs fixed relating to error handling in React, so it seems like this re-rendering is a result of a workaround for one of those bugs.
However, this should not be a problem for your app, as the render function should be pure (no side effects) in React apps. So basically, React can call your render function anytime it wants/needs to.
To work around this, you should avoid relying on the component not re-rendering and instead use an effect hook or similar to only fetch when certain props/state change.
Source: https://github.com/facebook/react/issues/16130#issuecomment-521637592
I think the error boundary is not actually catching the thrown error.
From https://reactjs.org/docs/error-boundaries.html:
Note
Error boundaries do not catch errors for:
Asynchronous code (e.g. setTimeout or requestAnimationFrame callbacks)
Asynchronous code includes Promises in this case.
See also https://reactjs.org/docs/error-boundaries.html#how-about-event-handlers:
Error boundaries do not catch errors inside event handlers.
If you need to catch an error inside event handler, use the regular JavaScript try / catch statement.
I'm using Apollo to interact with a GraphQL server in a Web application written in React. I'm trying to implement error handling in the application and relying on apollo-link-error for this.
Now, there are 2 categories of errors that I need to handle:
errors that can be handled locally in the component which does the Apollo query or mutation, i.e. an invalid form field on which I need to show contextual error information
errors that can be handled globally, for example by showing a toast notification displaying error details somewhere in the page
Clearly, once the error is handled locally I need it to not be handled globally, because it doesn't make much sense to show an error message next to a form field and a generic error via a toast message.
The first stumbling block I encountered when trying to implement this is that the global error handling logic triggers before the local error handling logic, which prevents me from being able to intercept the error locally and then find a way to prevent the global logic from kicking in.
I created codesandbox example which sets up an ApolloClient in the simplest possible way, uses the http and error links, and uses the react-apollo Query component to do a query for a resource that doesn't exist, generating an error.
I'm handling the error both in the onError callback of the Query component (so local error handling), and in the apollo-link-error handler (so global error handling), and printing to the console the errors.
It shows that the global error handling logic kicks in before the local error handling. I would need it to be the other way around.
I've published a library called react-apollo-network-status which handles exactly this use case. Let me know if it's useful to you!
The opt-in/-out behaviour for treating some errors locally is implemented by setting a context variable on the operation which can be read in the error link.