[Flight] Instrument the Console in the RSC Environment and Replay Logs on the Client #28384
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
facebook-github-bot
added
CLA Signed
React Core Team
sebmarkbage
commented
Feb 20, 2024
| patchConsole(console, 'log'); | ||
| patchConsole(console, 'table'); | ||
| patchConsole(console, 'trace'); | ||
| patchConsole(console, 'warn'); |
There was a problem hiding this comment.
There are some notable omissions from this list:
clear: This could make sense but it really refers to clearing the Flight runtime logs, it doesn't really imply that it should also clear the client.
time, timeLog, timeEnd, count, countReset: These run performance timings or state so it doesn't really make sense to replay these on the client. Instead we could run them in user space on the server and then write the result on the client.
profile, profileEnd, timeStamp: These really apply to profiles of an inspector running against the server so doesn't make sense to run on the client.
createTask and memory: These aren't side effects. You could log the result though. createTask might need deeper integration to forward the new stack.
context: This isn't really used anywhere. From what I can tell it's just built-in to v8 but without any UI. This could potentially actually be useful during replaying to put everything into an RSC context, depending on what the UI ends up looking like.
|
|
|
Notably if you're running the server in an embedded environment were the inspector is connected to both at the same time, then it might be better not to print them again since they're already in the same log with full inspection capabilities. Although ideally it should still track them for React DevTools to pick them up. We could potentially do something special in the |
sebmarkbage
force-pushed
the
flightlogs
branch
from
0361411
to
2317ab7
Compare
|
One flaw in the current serialization is that |
sebmarkbage
force-pushed
the
flightlogs
branch
3 times, most recently
from
a2ef462
to
d05a7b9
Compare
This allows complex objects to be logged and inspected on the client. We limit the depth of objects after 20 objects are written. This deals with cycles too. Because these objects aren't the complete model we can't cache them but if the full thing is already written, we can reuse that. This might not be fully ok since if there's an error:ed reference inside of it, it would error the log. This should never error nor suspend. Functions are emitted as eval of their source string to produce a similar looking function on the client. Unresolved Promises are serialized as infinite promises.
These aren't conceptually part of the request's render so we exit the request context for those.
sebmarkbage
force-pushed
the
flightlogs
branch
from
d05a7b9
to
609cb19
Compare
gnoff
approved these changes
Feb 21, 2024
Comment on lines
+99
to
+101
| // throw new Error( | ||
| // `Test did not tear down console.${methodName} mock properly.` | ||
| // ); |
There was a problem hiding this comment.
did you mean to deactivate this permanently?
There was a problem hiding this comment.
Yes. Although I'm not sure the best strategy to go forward with here. Ideally we'd delete it but maybe there's some way to restore it? I guess I'll leave it commented out for now.
github-actions bot
pushed a commit
that referenced
this pull request
Feb 21, 2024
…s on the Client (#28384) When developing in an RSC environment, you should be able to work in a single environment as if it was a unified environment. With thrown errors we already serialize them and then rethrow them on the client. Since by default we log them via onError both in Flight and Fizz, you can get the same log in the RSC runtime, the SSR runtime and on the client. With console logs made in SSR renders, you typically replay the same code during hydration on the client. So for example warnings already show up both in the SSR logs and on the client (although not guaranteed to be the same). You could just spend your time in the client and you'd be fine. Previously, RSC logs would not be replayed because they don't hydrate. So it's easy to miss warnings for example. With this approach, we replay RSC logs both during SSR so they end up in the SSR logs and on the client. That way you can just stay in the browser window during normal development cycles. You shouldn't have to care if your component is a server or client component when working on logical things or iterating on a product. With this change, you probably should mostly ignore the Flight log stream and just look at the client or maybe the SSR one. Unless you're digging into something specific. In particular if you just naively run both Flight and Fizz in the same terminal you get duplicates. I like to run out fixtures `yarn dev:region` and `yarn dev:global` in two separate terminals. Console logs may contain complex objects which can be inspected. Ideally a DevTools inspector could reach into the RSC server and remotely inspect objects using the remote inspection protocol. That way complex objects can be loaded on demand as you expand into them. However, that is a complex environment to set up and the server might not even be alive anymore by the time you inspect the objects. Therefore, I do a best effort to serialize the objects using the RSC protocol but limit the depth that can be rendered. This feature is only own in dev mode since it can be expensive. In a follow up, I'll give the logs a special styling treatment to clearly differentiate them from logs coming from the client. As well as deal with stacks. DiffTrain build for [9a5b6bd](9a5b6bd)
sebmarkbage
added a commit
that referenced
this pull request
Feb 21, 2024
Builds on top of #28384. This prefixes each log with a badge similar to how we badge built-ins like "ForwardRef" and "Memo" in the React DevTools. The idea is that we can add such badges in DevTools for Server Components too to carry on the consistency. This puts the "environment" name in the badge which defaults to "Server". So you know which source it is coming from. We try to use the same styling as the React DevTools. We use light-dark mode where available to support the two different color styles, but if it's not available I use a fixed background so that it's always readable even in dark mode. In Terminals, instead of hard coding colors that might not look good with some themes, I use the ANSI color code to flip background/foreground colors in that case. In earlier commits I had it on the end of the line similar to the DevTools badges but for multiline I found it better to prefix it. We could try various options tough. In most cases we can use both ANSI and the `%c` CSS color specifier, because node will only use ANSI and hide the other. Chrome supports both but the color overrides ANSI if it comes later (and Chrome doesn't support color inverting anyway). Safari/Firefox prints the ANSI, so it can only use CSS colors. Therefore in browser builds I exclude ANSI. On the server I support both so if you use Chrome inspector on the server, you get nice colors on both terminal and in the inspector. Since Bun uses WebKit inspector and it prints the ANSI we can't safely emit both there. However, we also can't emit just the color specifier because then it prints in the terminal. oven-sh/bun#9021 So we just use a plain string prefix for now with a bracket until that's fixed. Screen shots: <img width="758" alt="Screenshot 2024-02-21 at 12 56 02 AM" src="https://github.com/facebook/react/assets/63648/4f887ffe-fffe-4402-bf2a-b7890986d60c"> <img width="759" alt="Screenshot 2024-02-21 at 12 56 24 AM" src="https://github.com/facebook/react/assets/63648/f32d432f-f738-4872-a700-ea0a78e6c745"> <img width="514" alt="Screenshot 2024-02-21 at 12 57 10 AM" src="https://github.com/facebook/react/assets/63648/205d2e82-75b7-4e2b-9d9c-aa9e2cbedf39"> <img width="489" alt="Screenshot 2024-02-21 at 12 57 34 AM" src="https://github.com/facebook/react/assets/63648/ea52d1e4-b9fa-431d-ae9e-ccb87631f399"> <img width="516" alt="Screenshot 2024-02-21 at 12 58 23 AM" src="https://github.com/facebook/react/assets/63648/52b50fac-bec0-471d-a457-1a10d8df9172"> <img width="956" alt="Screenshot 2024-02-21 at 12 58 56 AM" src="https://github.com/facebook/react/assets/63648/0096ed61-5eff-4aa9-8a8a-2204e754bd1f">
github-actions bot
pushed a commit
that referenced
this pull request
Feb 21, 2024
Builds on top of #28384. This prefixes each log with a badge similar to how we badge built-ins like "ForwardRef" and "Memo" in the React DevTools. The idea is that we can add such badges in DevTools for Server Components too to carry on the consistency. This puts the "environment" name in the badge which defaults to "Server". So you know which source it is coming from. We try to use the same styling as the React DevTools. We use light-dark mode where available to support the two different color styles, but if it's not available I use a fixed background so that it's always readable even in dark mode. In Terminals, instead of hard coding colors that might not look good with some themes, I use the ANSI color code to flip background/foreground colors in that case. In earlier commits I had it on the end of the line similar to the DevTools badges but for multiline I found it better to prefix it. We could try various options tough. In most cases we can use both ANSI and the `%c` CSS color specifier, because node will only use ANSI and hide the other. Chrome supports both but the color overrides ANSI if it comes later (and Chrome doesn't support color inverting anyway). Safari/Firefox prints the ANSI, so it can only use CSS colors. Therefore in browser builds I exclude ANSI. On the server I support both so if you use Chrome inspector on the server, you get nice colors on both terminal and in the inspector. Since Bun uses WebKit inspector and it prints the ANSI we can't safely emit both there. However, we also can't emit just the color specifier because then it prints in the terminal. oven-sh/bun#9021 So we just use a plain string prefix for now with a bracket until that's fixed. Screen shots: <img width="758" alt="Screenshot 2024-02-21 at 12 56 02 AM" src="https://github.com/facebook/react/assets/63648/4f887ffe-fffe-4402-bf2a-b7890986d60c"> <img width="759" alt="Screenshot 2024-02-21 at 12 56 24 AM" src="https://github.com/facebook/react/assets/63648/f32d432f-f738-4872-a700-ea0a78e6c745"> <img width="514" alt="Screenshot 2024-02-21 at 12 57 10 AM" src="https://github.com/facebook/react/assets/63648/205d2e82-75b7-4e2b-9d9c-aa9e2cbedf39"> <img width="489" alt="Screenshot 2024-02-21 at 12 57 34 AM" src="https://github.com/facebook/react/assets/63648/ea52d1e4-b9fa-431d-ae9e-ccb87631f399"> <img width="516" alt="Screenshot 2024-02-21 at 12 58 23 AM" src="https://github.com/facebook/react/assets/63648/52b50fac-bec0-471d-a457-1a10d8df9172"> <img width="956" alt="Screenshot 2024-02-21 at 12 58 56 AM" src="https://github.com/facebook/react/assets/63648/0096ed61-5eff-4aa9-8a8a-2204e754bd1f"> DiffTrain build for [c027406](c027406)
huozhi
added a commit
to vercel/next.js
that referenced
this pull request
Feb 26, 2024
### React upstream changes - facebook/react#28438 - facebook/react#28436 - facebook/react#25954 - facebook/react#28434 - facebook/react#28433 - facebook/react#28432 - facebook/react#28415 - facebook/react#27903 - facebook/react#28430 - facebook/react#28424 - facebook/react#28400 - facebook/react#28422 - facebook/react#28423 - facebook/react#28412 - facebook/react#28418 - facebook/react#28421 - facebook/react#28417 - facebook/react#28399 - facebook/react#28408 - facebook/react#28350 - facebook/react#28387 - facebook/react#28403 - facebook/react#28384 - facebook/react#28409 - facebook/react#28398 - facebook/react#28405 - facebook/react#28328 - facebook/react#28402 - facebook/react#28386 - facebook/react#28388 - facebook/react#28379 - facebook/react#28383 - facebook/react#28390 - facebook/react#28389 - facebook/react#28382 - facebook/react#28348 Closes NEXT-2600
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
…s on the Client (facebook#28384) When developing in an RSC environment, you should be able to work in a single environment as if it was a unified environment. With thrown errors we already serialize them and then rethrow them on the client. Since by default we log them via onError both in Flight and Fizz, you can get the same log in the RSC runtime, the SSR runtime and on the client. With console logs made in SSR renders, you typically replay the same code during hydration on the client. So for example warnings already show up both in the SSR logs and on the client (although not guaranteed to be the same). You could just spend your time in the client and you'd be fine. Previously, RSC logs would not be replayed because they don't hydrate. So it's easy to miss warnings for example. With this approach, we replay RSC logs both during SSR so they end up in the SSR logs and on the client. That way you can just stay in the browser window during normal development cycles. You shouldn't have to care if your component is a server or client component when working on logical things or iterating on a product. With this change, you probably should mostly ignore the Flight log stream and just look at the client or maybe the SSR one. Unless you're digging into something specific. In particular if you just naively run both Flight and Fizz in the same terminal you get duplicates. I like to run out fixtures `yarn dev:region` and `yarn dev:global` in two separate terminals. Console logs may contain complex objects which can be inspected. Ideally a DevTools inspector could reach into the RSC server and remotely inspect objects using the remote inspection protocol. That way complex objects can be loaded on demand as you expand into them. However, that is a complex environment to set up and the server might not even be alive anymore by the time you inspect the objects. Therefore, I do a best effort to serialize the objects using the RSC protocol but limit the depth that can be rendered. This feature is only own in dev mode since it can be expensive. In a follow up, I'll give the logs a special styling treatment to clearly differentiate them from logs coming from the client. As well as deal with stacks.
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
Builds on top of facebook#28384. This prefixes each log with a badge similar to how we badge built-ins like "ForwardRef" and "Memo" in the React DevTools. The idea is that we can add such badges in DevTools for Server Components too to carry on the consistency. This puts the "environment" name in the badge which defaults to "Server". So you know which source it is coming from. We try to use the same styling as the React DevTools. We use light-dark mode where available to support the two different color styles, but if it's not available I use a fixed background so that it's always readable even in dark mode. In Terminals, instead of hard coding colors that might not look good with some themes, I use the ANSI color code to flip background/foreground colors in that case. In earlier commits I had it on the end of the line similar to the DevTools badges but for multiline I found it better to prefix it. We could try various options tough. In most cases we can use both ANSI and the `%c` CSS color specifier, because node will only use ANSI and hide the other. Chrome supports both but the color overrides ANSI if it comes later (and Chrome doesn't support color inverting anyway). Safari/Firefox prints the ANSI, so it can only use CSS colors. Therefore in browser builds I exclude ANSI. On the server I support both so if you use Chrome inspector on the server, you get nice colors on both terminal and in the inspector. Since Bun uses WebKit inspector and it prints the ANSI we can't safely emit both there. However, we also can't emit just the color specifier because then it prints in the terminal. oven-sh/bun#9021 So we just use a plain string prefix for now with a bracket until that's fixed. Screen shots: <img width="758" alt="Screenshot 2024-02-21 at 12 56 02 AM" src="https://github.com/facebook/react/assets/63648/4f887ffe-fffe-4402-bf2a-b7890986d60c"> <img width="759" alt="Screenshot 2024-02-21 at 12 56 24 AM" src="https://github.com/facebook/react/assets/63648/f32d432f-f738-4872-a700-ea0a78e6c745"> <img width="514" alt="Screenshot 2024-02-21 at 12 57 10 AM" src="https://github.com/facebook/react/assets/63648/205d2e82-75b7-4e2b-9d9c-aa9e2cbedf39"> <img width="489" alt="Screenshot 2024-02-21 at 12 57 34 AM" src="https://github.com/facebook/react/assets/63648/ea52d1e4-b9fa-431d-ae9e-ccb87631f399"> <img width="516" alt="Screenshot 2024-02-21 at 12 58 23 AM" src="https://github.com/facebook/react/assets/63648/52b50fac-bec0-471d-a457-1a10d8df9172"> <img width="956" alt="Screenshot 2024-02-21 at 12 58 56 AM" src="https://github.com/facebook/react/assets/63648/0096ed61-5eff-4aa9-8a8a-2204e754bd1f">
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
…s on the Client (#28384) When developing in an RSC environment, you should be able to work in a single environment as if it was a unified environment. With thrown errors we already serialize them and then rethrow them on the client. Since by default we log them via onError both in Flight and Fizz, you can get the same log in the RSC runtime, the SSR runtime and on the client. With console logs made in SSR renders, you typically replay the same code during hydration on the client. So for example warnings already show up both in the SSR logs and on the client (although not guaranteed to be the same). You could just spend your time in the client and you'd be fine. Previously, RSC logs would not be replayed because they don't hydrate. So it's easy to miss warnings for example. With this approach, we replay RSC logs both during SSR so they end up in the SSR logs and on the client. That way you can just stay in the browser window during normal development cycles. You shouldn't have to care if your component is a server or client component when working on logical things or iterating on a product. With this change, you probably should mostly ignore the Flight log stream and just look at the client or maybe the SSR one. Unless you're digging into something specific. In particular if you just naively run both Flight and Fizz in the same terminal you get duplicates. I like to run out fixtures `yarn dev:region` and `yarn dev:global` in two separate terminals. Console logs may contain complex objects which can be inspected. Ideally a DevTools inspector could reach into the RSC server and remotely inspect objects using the remote inspection protocol. That way complex objects can be loaded on demand as you expand into them. However, that is a complex environment to set up and the server might not even be alive anymore by the time you inspect the objects. Therefore, I do a best effort to serialize the objects using the RSC protocol but limit the depth that can be rendered. This feature is only own in dev mode since it can be expensive. In a follow up, I'll give the logs a special styling treatment to clearly differentiate them from logs coming from the client. As well as deal with stacks. DiffTrain build for commit 9a5b6bd.
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
Builds on top of #28384. This prefixes each log with a badge similar to how we badge built-ins like "ForwardRef" and "Memo" in the React DevTools. The idea is that we can add such badges in DevTools for Server Components too to carry on the consistency. This puts the "environment" name in the badge which defaults to "Server". So you know which source it is coming from. We try to use the same styling as the React DevTools. We use light-dark mode where available to support the two different color styles, but if it's not available I use a fixed background so that it's always readable even in dark mode. In Terminals, instead of hard coding colors that might not look good with some themes, I use the ANSI color code to flip background/foreground colors in that case. In earlier commits I had it on the end of the line similar to the DevTools badges but for multiline I found it better to prefix it. We could try various options tough. In most cases we can use both ANSI and the `%c` CSS color specifier, because node will only use ANSI and hide the other. Chrome supports both but the color overrides ANSI if it comes later (and Chrome doesn't support color inverting anyway). Safari/Firefox prints the ANSI, so it can only use CSS colors. Therefore in browser builds I exclude ANSI. On the server I support both so if you use Chrome inspector on the server, you get nice colors on both terminal and in the inspector. Since Bun uses WebKit inspector and it prints the ANSI we can't safely emit both there. However, we also can't emit just the color specifier because then it prints in the terminal. oven-sh/bun#9021 So we just use a plain string prefix for now with a bracket until that's fixed. Screen shots: <img width="758" alt="Screenshot 2024-02-21 at 12 56 02 AM" src="https://github.com/facebook/react/assets/63648/4f887ffe-fffe-4402-bf2a-b7890986d60c"> <img width="759" alt="Screenshot 2024-02-21 at 12 56 24 AM" src="https://github.com/facebook/react/assets/63648/f32d432f-f738-4872-a700-ea0a78e6c745"> <img width="514" alt="Screenshot 2024-02-21 at 12 57 10 AM" src="https://github.com/facebook/react/assets/63648/205d2e82-75b7-4e2b-9d9c-aa9e2cbedf39"> <img width="489" alt="Screenshot 2024-02-21 at 12 57 34 AM" src="https://github.com/facebook/react/assets/63648/ea52d1e4-b9fa-431d-ae9e-ccb87631f399"> <img width="516" alt="Screenshot 2024-02-21 at 12 58 23 AM" src="https://github.com/facebook/react/assets/63648/52b50fac-bec0-471d-a457-1a10d8df9172"> <img width="956" alt="Screenshot 2024-02-21 at 12 58 56 AM" src="https://github.com/facebook/react/assets/63648/0096ed61-5eff-4aa9-8a8a-2204e754bd1f"> DiffTrain build for commit c027406.
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.
When developing in an RSC environment, you should be able to work in a single environment as if it was a unified environment. With thrown errors we already serialize them and then rethrow them on the client.
Since by default we log them via onError both in Flight and Fizz, you can get the same log in the RSC runtime, the SSR runtime and on the client.
With console logs made in SSR renders, you typically replay the same code during hydration on the client. So for example warnings already show up both in the SSR logs and on the client (although not guaranteed to be the same). You could just spend your time in the client and you'd be fine.
Previously, RSC logs would not be replayed because they don't hydrate. So it's easy to miss warnings for example.
With this approach, we replay RSC logs both during SSR so they end up in the SSR logs and on the client. That way you can just stay in the browser window during normal development cycles. You shouldn't have to care if your component is a server or client component when working on logical things or iterating on a product.
With this change, you probably should mostly ignore the Flight log stream and just look at the client or maybe the SSR one. Unless you're digging into something specific. In particular if you just naively run both Flight and Fizz in the same terminal you get duplicates. I like to run out fixtures
yarn dev:regionandyarn dev:globalin two separate terminals.Console logs may contain complex objects which can be inspected. Ideally a DevTools inspector could reach into the RSC server and remotely inspect objects using the remote inspection protocol. That way complex objects can be loaded on demand as you expand into them. However, that is a complex environment to set up and the server might not even be alive anymore by the time you inspect the objects. Therefore, I do a best effort to serialize the objects using the RSC protocol but limit the depth that can be rendered.
This feature is only own in dev mode since it can be expensive.
In a follow up, I'll give the logs a special styling treatment to clearly differentiate them from logs coming from the client. As well as deal with stacks.