You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 9, 2023. It is now read-only.
This PR adds [JSON-RPC 2.0](https://www.jsonrpc.org/specification)-compliant notification handling for `JsonRpcEngine`.
- JSON-RPC notifications are defined as JSON-RPC request objects without an `id` property.
- A new constructor parameter, `notificationHandler`, is introduced. This parameter is a function that accepts JSON-RPC notification objects and returns `void | Promise<void>`.
- When `JsonRpcEngine.handle` is called, if a `notificationHandler` exists, any request objects duck-typed as notifications will be handled as such. This means that:
- Validation errors that occur after duck-typing will be ignored. At the moment, this just means that no error will be thrown if the `method` field is not a string.
- If basic validation succeeds, the notification object will be passed to the handler function without touching the middleware stack.
- The response from `handle()` will be `undefined`.
- No error will be returned or thrown, unless the notification handler itself throws or rejects.
- Notification handlers should not throw or reject, and it is the implementer's responsibility to ensure that they do not.
- If `JsonRpcEngine.handle` is called and no `notificationHandler` exists, notifications will be treated just like requests. This is the current behavior.
If you specify a `notificationHandler` when constructing the engine, JSON-RPC notifications passed to `handle()` will be handed off directly to this function without touching the middleware stack:
0 commit comments