I had no issues with error reporting until I updated to SDK 38 (now 39). Ever since LogBox, whenever there is an error, all I get is the packages listed in the error results. Is LogBox a step backwards or am I maybe missing something? It’s extremely difficult now to find exactly where an error is originating.
Below is an example of my latest error/stack trace… it is pretty much 100% useless to me. This is just the latest example but it is extremely rare that any actual file or line in an actual file that I created comes up - almost always only shows node modules.
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
You might have mismatching versions of React and the renderer (such as React DOM)
You might be breaking the Rules of Hooks
You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.
node_modules\react-native\Libraries\LogBox\LogBox.js:148:8 in registerError
node_modules\react-native\Libraries\LogBox\LogBox.js:59:8 in errorImpl
node_modules\react-native\Libraries\LogBox\LogBox.js:33:4 in console.error
node_modules\expo\build\environment\react-native-logs.fx.js:27:4 in error
node_modules\react-native\Libraries\Core\ExceptionsManager.js:104:6 in reportException
node_modules\react-native\Libraries\Core\ExceptionsManager.js:171:19 in handleException
node_modules\react-native\Libraries\Core\setUpErrorHandling.js:24:6 in handleError
node_modules\expo-error-recovery\build\ErrorRecovery.fx.js:9:32 in ErrorUtils.setGlobalHandler$argument_0
node_modules\regenerator-runtime\runtime.js:63:36 in tryCatch
node_modules\regenerator-runtime\runtime.js:293:29 in invoke
node_modules\regenerator-runtime\runtime.js:63:36 in tryCatch
node_modules\regenerator-runtime\runtime.js:154:27 in invoke
node_modules\regenerator-runtime\runtime.js:164:18 in PromiseImpl.resolve.then$argument_0
node_modules\react-native\node_modules\promise\setimmediate\core.js:37:13 in tryCallOne
node_modules\react-native\node_modules\promise\setimmediate\core.js:123:24 in setImmediate$argument_0
node_modules\react-native\Libraries\Core\Timers\JSTimers.js:130:14 in _callTimer
node_modules\react-native\Libraries\Core\Timers\JSTimers.js:181:14 in _callImmediatesPass
node_modules\react-native\Libraries\Core\Timers\JSTimers.js:441:30 in callImmediates
node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:387:6 in __callImmediates
node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:135:6 in __guard$argument_0
node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:364:10 in __guard
node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:134:4 in flushedQueue
[native code]:null in flushedQueue
[native code]:null in invokeCallbackAndReturnFlushedQueue
Thanks, but that would be so incredibly time consuming doing that all the time. If I haven’t been working on the project for a few days, I don’t even know what file to start with besides app.js and working out from there… again, that would be incredibly time consuming and make expo/react one of the worst error-reporting languages I’ve ever seen. I’m looking into other possibilities like using a linter… but not sure if that will help or not.
i’m not suggesting that you do it all the time. my understanding is that you have some issue after upgrading your app, and if you’re unable to find the source of the problem then this is a good approach to take.
it’s possible that logbox has introduced some regressions in exception reporting, if you can provide some concrete reproducible examples where the errors this would be helpful!
i looked into this further and was able to reproduce a similar error quite easily. the logs in expo-cli were not so useful, but the trace inside of the logbox was:
the reason the traces are not so valuable in expo-cli is that we are filtering out the “component stack” from error messages currently. this used to not be a particularly useful piece of data but react has improved this greatly over time. so, i’ve decided to add it back in expo@39.0.5 - install that version of the package to see the component stack in error messages in expo-cli.
That is very cool. I have i little more to add but am out for the night i will reply with a little more info when I’m back. But thank you very much for that @notbrent!
Before re-installing 39.0.5, I decided to try to reproduce a behavior I thought was strange. So it was not giving me any hint of where the error was located - even in the redbox it was showing code from one of the node modules (first screenshot). But when I remove LaborFormScreen.js from my AppNavigator, but leave the import, it shows the same error but actually tells me that it’s in LaborFormScreen.js (2nd screenshot). Then, if I do the same thing on that file (remove the JSX that calls a deeper child component, but leave the import), it shows that it is coming from that deeper child element. So for some reason it has problems following the error deeper into child components unless you remove the actual JSX that calls the component and leave the import. And I don’t know if this is even stranger or if maybe the error is just cached, but if I put everything back (the JSX mostly), it now shows the deeper component is throwing the error (screenshot 2 also).
So I tried installing expo 39.0.5 (I was running 39.0.2 before according to my package.json file). I’m still not seeing the component stack but maybe I need to uninstall it or something? I ran both ‘npm install -g expo-cli’ and ‘npm install expo@39.0.5’. Checked ‘npm ls expo’ and it shows ‘-- expo@39.0.5’. So I believe I have the new version.
it seems like the specific class of error that you are seeing here just doesn’t produce a good trace. it’s hard to say why exactly, but if you can help to reproduce it we can investigate further
Appreciate that, Brent. It is a fairly large app (25 custom components, 9 screens, bottom tab navigator), but I will try again removing components and hopefully this time I will find the culprit. I’m in the process of re-building the app as I upgraded from [I think] ~35/36 to 39 and the amount of issues that caused made it easier to re-build it screen by screen than to try to fix all the incompatibilities. The odd thing is that on Friday everything was working fine. Last thing I seen was the app on an iPhone using Expo, with no warnings or errors. This invalid hood calls just showed up Tuesday without updating expo or doing really anything with the app… but it wouldn’t surprise me (nor be the first time) if VS Code had altered or reverted some of my changes - and I had actually fixed about 5 or 6 of those invalid hook calls before so maybe I just need to look for those again - a little deeper.
I will report back either way, but fingers crossed I find it so I’m not taking your time and can summarize what happened in case it is useful for future LogBox dev.
I found the issue. It was much easier today. I didn’t realize the component that I had thought might contain the issue was imported from another component besides the one where I had commented it out - so I had thought that was not that component (but it was). It was exactly what it said it was (hook called outside of a function). Maybe I had just not saved the file Friday and when I closed my IDE and it had auto-saved it.
Since that, I am receiving a few other errors, but they are very precise and pinpoint my issues perfectly now (component + line number) - so thanks for putting components back into the stack trace Brent! It helps a lot!
If there is anything I can do to also pinpoint why it was not showing the erroneous component, let me know.
