I appreciate the convenience of the expo XDE logging pane, automatically aggregating device logs to this console. However this is obviously only available in a development phase.
My basic question is: what happens to logging probes in a published expo application?
Are logs retained on the device itself (i.e. take up space on the device), or are they discarded in the bit bucket?
If retained, how can I access them in a production environment? I have seen the “Manually access device logs” discussion in the expo docs, however this still seems more relevant to development than production.
The reason I ask is I typically utilize a highly configurable logging utility (that wraps console.log), filtering logs at run-time. In a production setting, this is typically configured to only emit error-level logs. However, for diagnostic purposes, these filters can be dynamically re-configured at run-time to emit more log levels (typically through a hidden easter egg).
Obviously this is only useful, if you have a mechanism to access the emitted logs.
I have seen the expo-reference to Sentry (which I have not used), but this seems to be more related to crash reporting, verses log accumulation.
I am curious as to if there are any thoughts on how aggregating production logs could operate today, or in a future expo enhancement?
As an addendum, I exposed some diagnostic console .log()/.warn()/.error() probes in a published expo app.
The .log() and .warn() had no apparent visible impact (such as the yellow warning toast).
However, the .error() actually restarted my app from the beginning (again with no visible logs - such as the red error screen). This app restart behavior was completely unexpected … Thoughts?
hey @kevinast, unfortunately we dont currently have a built in service for logging. As things currently stand, you could offload your logs to a server (ie) use something like Segment API https://segment.com/. Also, if you could input your feature requests at Feature Requests | Expo, that would be awesome. We use canny to keep track of the features to next implement.
Thanks for your reply. I will do some research on Segment.
From my question above, two outstanding aspects I need to understand are:
For a published expo app, do console.logs consume device resources (i.e. space and cpu cycles), or are they somehow discarded (ex: no-oping the console.log())?
The reason I ask is if they do utilize device resources, a developer may decide to omit any logging probes from published apps.
The answer to this question is an important point that you may want to consider mentioning in your docs.
Can you explain why my test (mentioned above) - emitting a console.error() in a published app, caused the app to restart? I did not expect this behavior at all.
Hey @kevinast, if you take a look at the docs here, there’s an explanation for #2.
In Production: If your published app encounters a fatal JS error, Expo will immediately reload your app. If the error happens very quickly after reloading, Expo will show a generic error screen with a button to try manually reloading.
You can use the ErrorRecovery API to set the reloaded project’s initial props (and send your user back to the screen where the error occurred).
SideTopic:Expos’ interpretation of “fatal JS error” being a log-based console.error() is a bit of an “over reach” (IMHO), as opposed to say an uncaught exception (which I realize is more problematic to detect). This is all inner related to how you are using logging. I suppose if I feel strongly about this I can followup with various suggestions to the expo team.
Hey @kevinast, just coming back to this thread after ages. Hopefully this was clear already, but I later realized that the crash happens on console.error() on Android, but not on iOS. Cheers!