feat: Implement reanimated logger with stack trace customization #6364
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MatiPl01
changed the base branch from
main
to
@matipl01/mutable-value-access-during-render-warning
Errors before and after changes
|
|
Closed in favor of #6385 |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 26, 2024
## Summary This PR is a much cleaner approach than proposed in #6364. It includes metro-config modification which is essential to collapse logs from reanimated source code, which aren't helpful to the user while tracking down the issue. The previous approach was trimming logs from reanimated source code completely - this approach just collapses them, so that they are still available to the user and can be revealed above the presented stack trace part. ## General idea To get better logs, I had to implement the following 2 changes: 1. **metro config** - the `symbolicator` must have been added to properly collapse stack frames that aren't meaningful to the user, 2. **logger object** - the new logger object uses `LogBox.addLog` method, thanks to which we can get pretty stack traces when we log a warning from the UI thread (before such warnings didn't include meaningful stack trace as error stack was created inside `LogBox` after `runOnJS` was called, so we were getting a bit limited JS stack - see [example 11](#6387 (comment)) in the follow up PR). ## Example improvement (tested on a real project to see if it works there as well) - current logs either point to the reanimated source code or aren't readable at all (if warning is logged from the UI thread as in the example below) - new logger shows correct destination of the issue culprit in the code frame, collapses stack frames in the call stack that aren't interesting to the user (reanimated source code) and focuses on the file where the user included problematic code | Before | After | |-|-| | <video src="https://github.com/user-attachments/assets/a5302586-f4d0-4636-8bd8-6c406c9d8c73" /> | <video src="https://github.com/user-attachments/assets/3121636f-69a2-4b6f-8f38-b1889d4c62e1" /> | ## Test plan See the example in the next PR (#6387). --------- Co-authored-by: Tomasz Żelawski <[email protected]>
Latropos
pushed a commit
that referenced
this pull request
Aug 26, 2024
## Summary This PR is a much cleaner approach than proposed in #6364. It includes metro-config modification which is essential to collapse logs from reanimated source code, which aren't helpful to the user while tracking down the issue. The previous approach was trimming logs from reanimated source code completely - this approach just collapses them, so that they are still available to the user and can be revealed above the presented stack trace part. ## General idea To get better logs, I had to implement the following 2 changes: 1. **metro config** - the `symbolicator` must have been added to properly collapse stack frames that aren't meaningful to the user, 2. **logger object** - the new logger object uses `LogBox.addLog` method, thanks to which we can get pretty stack traces when we log a warning from the UI thread (before such warnings didn't include meaningful stack trace as error stack was created inside `LogBox` after `runOnJS` was called, so we were getting a bit limited JS stack - see [example 11](#6387 (comment)) in the follow up PR). ## Example improvement (tested on a real project to see if it works there as well) - current logs either point to the reanimated source code or aren't readable at all (if warning is logged from the UI thread as in the example below) - new logger shows correct destination of the issue culprit in the code frame, collapses stack frames in the call stack that aren't interesting to the user (reanimated source code) and focuses on the file where the user included problematic code | Before | After | |-|-| | <video src="https://github.com/user-attachments/assets/a5302586-f4d0-4636-8bd8-6c406c9d8c73" /> | <video src="https://github.com/user-attachments/assets/3121636f-69a2-4b6f-8f38-b1889d4c62e1" /> | ## Test plan See the example in the next PR (#6387). --------- Co-authored-by: Tomasz Żelawski <[email protected]>
tjzel
added a commit
that referenced
this pull request
Aug 28, 2024
This PR is a much cleaner approach than proposed in #6364. It includes metro-config modification which is essential to collapse logs from reanimated source code, which aren't helpful to the user while tracking down the issue. The previous approach was trimming logs from reanimated source code completely - this approach just collapses them, so that they are still available to the user and can be revealed above the presented stack trace part. To get better logs, I had to implement the following 2 changes: 1. **metro config** - the `symbolicator` must have been added to properly collapse stack frames that aren't meaningful to the user, 2. **logger object** - the new logger object uses `LogBox.addLog` method, thanks to which we can get pretty stack traces when we log a warning from the UI thread (before such warnings didn't include meaningful stack trace as error stack was created inside `LogBox` after `runOnJS` was called, so we were getting a bit limited JS stack - see [example 11](#6387 (comment)) in the follow up PR). (tested on a real project to see if it works there as well) - current logs either point to the reanimated source code or aren't readable at all (if warning is logged from the UI thread as in the example below) - new logger shows correct destination of the issue culprit in the code frame, collapses stack frames in the call stack that aren't interesting to the user (reanimated source code) and focuses on the file where the user included problematic code | Before | After | |-|-| | <video src="https://github.com/user-attachments/assets/a5302586-f4d0-4636-8bd8-6c406c9d8c73" /> | <video src="https://github.com/user-attachments/assets/3121636f-69a2-4b6f-8f38-b1889d4c62e1" /> | See the example in the next PR (#6387). --------- Co-authored-by: Tomasz Żelawski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR implements better logger to ensure that call stacks in logs are clear and properly show the culprit of the issue.
he default default stack trace, included after calling
console.warn/console.error, contains all calls up with function calls in the library source code and evenconsolecall itself. It is a bit confusing, because the real source of the problem often is not visible in the call stack until the complete call stack is revealed and the proper call is found.This new logger is intended to make calls stacks more readable by excluding unnecessary calls from reanimated source code in some warnings where it's better to show the place in the user code which caused the issue. It also adds the
[Reanimated]prefix to all logs automatically, so it is no longer necessary to remember about adding this prefix manually in every log message.Remarks
Some error/warning call stacks cannot be beautified, especially if these are native stacks or execution of the specific function is not tied to the component (e.g. the component schedules the animation but the error is thrown after the animation starts).
Test plan