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
Copy file name to clipboardExpand all lines: docs/javascript/components_rpc_api.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,8 @@ The module should roughly map to the route parameters for simplicity, for exampl
13
13
The `Result` module provides a consistent interface to interact with the API.
14
14
A comprehensive implementation can be found in `WoltLabSuite/Core/Api/Comments/RenderComment.ts`:
15
15
16
+
!!! info "WoltLab Suite 6.2 added a helper method for infallible requests that greatly reduces the boiler-plate code required for RPC endpoints that do not return errors in general. It is strongly recommended to use this new function instead unless you explicitly need to handle errors yourself. See the section on infallible requests to learn more."
@@ -68,3 +70,24 @@ Any network errors or other kind of client errors will fail hard.
68
70
69
71
The returned value from the server will be attempted to be parsed into an `WoltLabSuite/Core/Api/Error` that represents the well-defined error response from the PHP RPC API.
70
72
Validation errors can easily be detected through the `.getValidationError()` method of `ApiError` which returns `undefined` for all other error classes.
73
+
74
+
## Infallible RPC Requests
75
+
76
+
An RPC request is considered infallible if there is no reasonable situation where the request should ever fail.
77
+
This is true for most RPC endpoints that do not explicitly return errors and instead should only fail if something unexpected goes wrong.
78
+
79
+
Using `ApiResult` requires the developer to explicitly handle unexpected errors either explicitly or implicitly through `.unwrap()` on the result.
80
+
There have been cases where developers only checked for `if (result.ok) { /* … */ }` but completely neglected the error that was returned by the server.
81
+
82
+
It is strongly recommended to use this simplified call instead whenever you are not expecting any errors to be returned from the API call.
0 commit comments