Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Flight] Serialize rate limited objects in console logs as marker an …
…increase limit (#30294) This marker can then be emitted as a getter. When this object gets accessed we use a special error to let the user know what is going on. <img width="1350" alt="Screenshot 2024-07-08 at 10 13 46 PM" src="https://github.com/facebook/react/assets/63648/e3eb698f-e02d-4394-a051-ba9ac3236480"> When you click the `...`: <img width="1357" alt="Screenshot 2024-07-08 at 10 13 56 PM" src="https://github.com/facebook/react/assets/63648/4b8ce1cf-d762-49a4-97b9-aeeb1aa8722c"> I also increased the object limit in console logs. It was arbitrarily set very low before. These limits are per message. So if you have a loop of many logs it can quickly add up a lot of strain on the server memory and the client. This is trying to find some tradeoff. Unfortunately we don't really do much deduping in these logs so with cyclic objects it ends up maximizing the limit and then siblings aren't logged. Ideally we should be able to lazy load them but that requires a lot of plumbing to wire up so if we can avoid it we should try to. If we want to that though one idea is to use the getter to do a sync XHR to load more data but the server needs to retain the objects in memory for an unknown amount of time. The client could maybe send a signal to retain them until a weakref clean up but even then it kind of needs a heartbeat to let the server know the client is still alive. That's a lot of complexity. There's probably more we can do to optimize deduping and other parts of the protocol to make it possible to have even higher limits.
- Loading branch information