Open elainen opened 6 years ago
This may be a bigger project for our entire hz stack rather than just hz-core, since we have discussed wanting this to be part of a bigger logging configuration that we can use for new projects. See https://github.com/hzdg/dev-team/issues/9.
I think we can break it down on two things then - have a component that is responsible for reporting errors to sentry(it could be used in data fetching apis, for example) and another part will go to our cli and be responsible for automated setup of sentry for the project. What do you think?
On the component side, maybe we can build something that is sentry-agnostic and pluggable, like:
ErrorContextProvider
that provides a report function to descendantsErrorContextBoundary
that consumes that report function and calls it with errors it catchesIn this kind of setup, the report function might need its own spec, like:
Promise<boolean>
?)With this kind of architecture, we could then create a SentryErrorContextProvider
that provides a raven-js backed report function, but without explicitly coupling ourselves to Sentry for error reporting.
Is this too much complexity for no benefit? Not sure, but seems smart to me to future-proof where we can
What other error reporting services might we want to use? The only one i'm aware of is The Wharf App using Crashlytics
Should this be tied into a more general 'reporting' framework that could solve other use cases like #19, or general tracking (page view, clicks, etc)?
Wondering if this can also be linked with the e2e thing @toastcrunch is building with cypress.
found an example of crash reporting using cypress.io+sentry.io https://glebbahmutov.com/blog/connecting-crash-reporting-with-end-to-end-tests/
Would be linked to Sentry.
https://sentry.io/for/react/