TypeScript types don't match implementation

[paavohuhtala]

Currently, the TypeScript type definitions do not match the documentation nor the implementation. Here are the problems I've encountered so far in one afternoon of integrating the library:

• <ErrorBoundary> has a fallbackUI prop, which is a ReactNode (the result of rendering a component) in types, but is assumed to be a function (a functional component) in the implementation. The correct type would most likely be React.ComponentType<{}> or React.FC<{}>.
• historyContext has multiple issues:
  • The documentation (and implementation) claims to support both History v4 and History v5, but the types are only compatible with V4.
  • filter and formatter functions receive location as a string, but it is in fact a Location object, not a string.
  • filter and formatter are documented as optional, but they are required arguments in types.
  • Furthermore, the types are not correct even for V4:
    • The function returns a callback which receives an object consisting of action and filter, but this seems like a copy-paste mistake and the correct signature is probably (location: Location, action: string).
    • You need to define your own Location type, unless you want to take a dependency on history.

[gtupak]

+1 for the fallbackUI problem. What would be a good workaround to fix that for now?

[dwightgunning]

As a workaround, I followed this guide to overriding the type definitions (in reality inserting new type definitions that have higher precedence).

Versions:

• @rollbar/react: ^0.11.1
• @types/node: ^16.8.4
• @types/react: ^18.0.25
• rollbar: ^2.25.2
• react: ^18.2.0
• node: ^16.17.0
• typescript: ^4.8.3

[ziperfal123]

Any updates about this issue? tnx

[walkingbrad]

+1 I'm itching for a fix. For context, this issue occurs with React 18 and not React 17