RFC: Hydrogen Logging and Error Handling #288
Replies: 4 comments 2 replies
-
The main metrics, TTFB/FCP/LCP, should still be captured by browser because that is how most performance capturing library are capturing it. Not sure how well <Product>
<ProductDetail />
<ProductReview />
<PageLoaded />
</Product> Say all 3 nested components are client components: We have a race condition on which client component file gets downloaded first and executed first - since streaming is out-of-order. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the write up! Some comments/ideas here: ErrorsI agree with the defensive validation on input. About error handling, can we rely on Error Boundaries for most of it? Perhaps we could provide an However, we might need different error hooks for server vs browser, since services for error handling normally use different libraries for each environment... not sure how this would work.
Does this mean we use a server redirect to LoggingSome random thoughts:
Not sure what to think about the performance metrics. Perhaps it could be handled separately in another RFC 🤔 |
Beta Was this translation helpful? Give feedback.
-
I agree that performance metric should be in another RFC |
Beta Was this translation helpful? Give feedback.
-
I think this sounds great. I wasn't sold on having to import a |
Beta Was this translation helpful? Give feedback.
-
RFC: Hydrogen Logging and Error Handling
In order to successfully run an app in production, Hydrogen needs to have a complete solution for logging and error handling.
Errors
There are a variety of ways a web application can fail. When and how the error occurs can make it very difficult to diagnose and debug the problem. In addition to that, the merchant is likely to want to customize the error user experience.
No matter where an error occurs, we need to provide the tools to make it easy to track, resolve, and customize.
Dev mode
During development mode, errors should be quickly exposed to the user in an actionable way.
shopify.config.js
should be validated.There are techniques for adding asynchronous stack traces to errors. At the asynchronous boundaries that we control, we should explore techniques to add asynchronous stack traces.
Prod Mode
During production mode, error details should not be exposed to the user. We should have good default error pages that are easily customizable by the merchant. The app should never render a blank white page when an error has been encountered.
Errors need to be tracked by the merchant. There are many third party error tracking services available, for example: sentry, trackjs, raygun, bugsnag, newrelic. We should easily support adding any third party error tracking service. We should have documentation on how to add at least one or two (maybe we could partner with one in particular).
We need a UX strategy for production errors in the starter template. Right now, all pages assume network requests succeed. What are best practice industry standards for when data fails to load?
For example,
Some errors happen further up in the stack. Maybe the whole RSC tree fails to render. There needs to be a fallback error screen, that can render in fatal unexpected scenarios. This screen is vanilla and self-contained HTML file that is customizable by the merchant developer. A new HTML file will be created in
/public/error.html
. The default verbiage and styling of this page is yet to be defined.Logging
Logging is similar to error handling, but more general in that anything can be logged. Right now Hydrogen has no formal strategy for logging.
console.log
andconsole.error
are used directly throughout the server code. We should add a logging and error abstraction, that will make it easy for the merchant to use different error and logging services.For example:
If logs are written within the context of the request, automatically the request properties can be added to the logline. Because of this, a contextual log object should be available throughout the request lifecycle. To do this, a log context should be created, and the user can use a hook to access logs in the request context.
There needs to be a way to hook into hydrogen logging to provide a custom logging implementation:
Performance Logging
We should make it easy for users to log performance metrics. Web vital metrics are a bit tricky for single-page applications, because between server and client rendering and rehydration, it isn’t always clear when the events occurred. We can make it easy by providing utilities to define when the app has loaded.
<PageLoaded>
is a client component that flags when the app has loaded. Where this component is rendered is up to the developer, but once it renders, it marks the page as “loaded”. This is used for timing measurements.Performance metrics are recorded as
log.info
events:<PageLoaded />
component to render (from initial request).Maybe other perf metrics? RSC/rehydration metrics?
Other Questions
Should logging events be related to analytics events? Shopify/hydrogen#92
Beta Was this translation helpful? Give feedback.
All reactions