You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve been exploring the react‑scan codebase and really appreciate the instrumentation and re-render tracking features. With the rise of React Server Components (and Next.js’s implementation of them), I was wondering if you’ve considered adding a feature to distinguish between server and client components within react‑scan. It was difficult to distinguish between Server and Client Components, so it was inconvenient to optimize the performance.
One idea is to leverage build-time static analysis—such as using a Babel plugin or Webpack loader—to detect the presence of the "use client" directive and inject metadata into components. This metadata could then be used at runtime to label components as either “Server” or “Client” in the react‑scan UI. Alternatively, a runtime heuristic based on Fiber tree analysis might be explored, though it may have its own challenges.
Do you have any plans to implement this feature, or what are your thoughts on this approach? I’d be interested in contributing or discussing further if there’s interest in integrating server/client component differentiation into react‑scan.
Thank you for your great work on this project!
Best regards,
The text was updated successfully, but these errors were encountered:
One idea is to leverage build-time static analysis
We have a lot of ideas that would require static analysis (example would be injecting source locations), but isn't completely in consideration right now, this goes the same for this idea.
Alternatively, a runtime heuristic based on Fiber tree analysis might be explored, though it may have its own challenges.
iirc there's no distinction in the Fiber if it is a server or a client component, except perhaps if it returns a Promise, but then we don't exactly know if it's an "async client component", a normal component that returns a Promise (since Promise is now a valid JSX element) or a server component.
No worries though, this isn't completely out of the window, but currently the solution is just limited.
Hi react‑scan team,
I’ve been exploring the react‑scan codebase and really appreciate the instrumentation and re-render tracking features. With the rise of React Server Components (and Next.js’s implementation of them), I was wondering if you’ve considered adding a feature to distinguish between server and client components within react‑scan. It was difficult to distinguish between Server and Client Components, so it was inconvenient to optimize the performance.
One idea is to leverage build-time static analysis—such as using a Babel plugin or Webpack loader—to detect the presence of the "use client" directive and inject metadata into components. This metadata could then be used at runtime to label components as either “Server” or “Client” in the react‑scan UI. Alternatively, a runtime heuristic based on Fiber tree analysis might be explored, though it may have its own challenges.
Do you have any plans to implement this feature, or what are your thoughts on this approach? I’d be interested in contributing or discussing further if there’s interest in integrating server/client component differentiation into react‑scan.
Thank you for your great work on this project!
Best regards,
The text was updated successfully, but these errors were encountered: