Live data from Hacker News

How to Inspect React Server Component Activity with Next.js and OpenTelemetry

dash0.com

1–10 of 52 posts

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#2
Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#3
post #2

Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).

Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#4
post #2

Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).

Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?

And these days, you use the same browser debug tools to attach to nodejs.

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#5
post #2

Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).

Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?

> Read the logs.

I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#6
post #5

Earlier quoted context omitted.

Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?

> Read the logs. I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...

how else would one reproduce a bug? in production?

or is it best practice to patch with logs only without reproduction

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#7
post #2

Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).

Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?

What's missing are the summaries that web developers are commonly used to. For example, the network tab in the developer tools. It is arguably very handy for development – and often more actionable than having to step through individual requests.

But you are of course also right that you can just attach a debugger. That's also called out in the article.

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#8
I'm really not a fan of the "what colour is your component" situation introduced by RSC.

RSC is a cool feature, but I'm still not convinced that the added churn of thinking about "colours" when building components and structuring the component tree is worth it for the benefits it gives.

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#9
post #6
post #5

Earlier quoted context omitted.

> Read the logs. I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...

how else would one reproduce a bug? in production? or is it best practice to patch with logs only without reproduction

There are often additional hints to go by, e.g., the executed network requests, the user path taken or "breadcrumbs", i.e., custom events captured.

Of course that requires a certain operational maturity.

Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry

#10

I'm really not a fan of the "what colour is your component" situation introduced by RSC. RSC is a cool feature, but I'm still not convinced that the added churn of thinking about "colours" when building components and structuring the component tree is worth it for the benefits it gives.

It adds notable complexity, and I sense that the whole server/client side component reality is wildly ill-understood.
Post reply on HN