Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Distinguish Server vs. Client Components #246

Open
KimCookieYa opened this issue Feb 12, 2025 · 1 comment
Open

[Feature Request] Distinguish Server vs. Client Components #246

KimCookieYa opened this issue Feb 12, 2025 · 1 comment

Comments

@KimCookieYa
Copy link

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,

@lxsmnsyc
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants