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

React Navigation Plugin in TypeScript #1481

Open
henrymoulton opened this issue Jul 19, 2021 · 5 comments
Open

React Navigation Plugin in TypeScript #1481

henrymoulton opened this issue Jul 19, 2021 · 5 comments
Labels
backlog We hope to fix this feature/bug in the future feature request Request for a new feature

Comments

@henrymoulton
Copy link

Description

When installing the React Navigation plugin in a TypeScript project it fails to typecheck const { createNavigationContainer } = Bugsnag.getPlugin('reactNavigation')

TS2339: Property 'createNavigationContainer' does not exist on type 'BugsnagPluginReactNavigationResult | undefined'.

Describe the solution you'd like

Better typings in the package or some docs on how to workaround

https://docs.bugsnag.com/platforms/react-native/react-native/navigation-libraries/
https://github.com/bugsnag/bugsnag-js/blob/next/packages/plugin-react-navigation/react-navigation.js

    "@bugsnag/plugin-react-navigation": "^7.10.0",
    "@bugsnag/react-native": "^7.10.5",
@johnkiely1
Copy link
Member

Hi @henrymoulton,

The best way to work around this would be by adding a ! at the end of the line so it becomes:
const { createNavigationContainer } = Bugsnag.getPlugin('reactNavigation')!

We are considering making some Typescript specific changes to the docs to better clarify this and I'll let you know of updates on that.

@johnkiely1 johnkiely1 added awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. backlog We hope to fix this feature/bug in the future labels Jul 21, 2021
@henrymoulton
Copy link
Author

Thanks @johnkiely1 that's not an ideal workaround I think for now I'm going to avoid Bugsnag plugins and just replicate the functionality.

Feedback is: I'm a big fan of your SDK and bring it to every client I can, but just feel like the docs/work around plugins (at least for React Native) doesn't feel like it has the polish of other React Native specific things that you guys support e.g. CodePush.

Another example but separate issue is Jest Mocking / TypeScript support for the the .createErrorBoundary plugin

   TypeError: Cannot read property 'createErrorBoundary' of undefined

      21 | };
      22 | export const AppProviders = () => {
    > 23 |   const ErrorBoundary = Bugsnag.getPlugin("react").createErrorBoundary(React);

Obviously separate issue but just wanted to illustrate that it feels like plugins could be super useful but lack a bit of love.

Don't worry my love for Bugsnag endures ❤️

@xljones
Copy link
Contributor

xljones commented Jul 26, 2021

👋. Just wanted to clarify why this workaround is the right thing to do. There's two scenarios that can occur:

  • before Bugsnag.start() is called, where plugins are undefined, and
  • after Bugsnag.start(), where plugins are defined (as something non-undefined).

So, whilst the addition of ! forces the TS compiler to ignore the TypeError, additionally adding a guard around the instantiation of the plugin will allow you to see whether the plugin is actually ready to be started. The current types are correct as plugins can exist in more than one state.

A simple method for guarding against the error boundary plugin (for example) was discussed here, although this was under a slightly different context, the same method can be applied), the point being, if you guard against this and start to see plugins undefined, it means they're being applied to early and this timing should be addressed.

Hope this helps solve your issue and allow you to continue using the Bugsnag plugins :)

@xljones xljones added feature request Request for a new feature and removed awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. labels Jul 26, 2021
@henrymoulton
Copy link
Author

henrymoulton commented Oct 12, 2021

@xander-jones sorry for dropping this - great explanation.

@henrymoulton
Copy link
Author

@xander-jones going to continue discussion in #1112.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog We hope to fix this feature/bug in the future feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

3 participants