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

Create ErrorBoundary component linked to logging #4

Open
elainen opened this issue Mar 26, 2018 · 6 comments
Open

Create ErrorBoundary component linked to logging #4

elainen opened this issue Mar 26, 2018 · 6 comments
Labels
Type: New Component A new component to make

Comments

@elainen
Copy link
Contributor

elainen commented Mar 26, 2018

Would be linked to Sentry.

https://sentry.io/for/react/

@elainen elainen added the Type: New Component A new component to make label Apr 23, 2018
@aamorozov
Copy link
Contributor

@aamorozov aamorozov self-assigned this Apr 16, 2019
@elainen
Copy link
Contributor Author

elainen commented Apr 22, 2019

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.

@aamorozov
Copy link
Contributor

aamorozov commented Apr 22, 2019

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?

@lettertwo
Copy link
Contributor

lettertwo commented Apr 22, 2019

On the component side, maybe we can build something that is sentry-agnostic and pluggable, like:

  • An ErrorContextProvider that provides a report function to descendants
  • An ErrorContextBoundary that consumes that report function and calls it with errors it catches

In this kind of setup, the report function might need its own spec, like:

  • It takes an error and some optional context (maybe we should consult raven-js and any other popular error reporting tools for API inspo)
  • It has a return protocol to indicate whether or not it reported the error (Promise<boolean>?)
  • Maybe we need a compositional tool that can take two or more report functions and compose them such that:
    • They are called in order (or in parallel?)
    • They can prevent later report functions from being called? (not sure if this is useful or not)

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.


Questions

  • 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 Unique Anon ID generator #19, or general tracking (page view, clicks, etc)?

@elainen
Copy link
Contributor Author

elainen commented Feb 10, 2020

Wondering if this can also be linked with the e2e thing @toastcrunch is building with cypress.

@toastcrunch
Copy link

found an example of crash reporting using cypress.io+sentry.io https://glebbahmutov.com/blog/connecting-crash-reporting-with-end-to-end-tests/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: New Component A new component to make
Projects
None yet
Development

No branches or pull requests

4 participants