This repository has been archived by the owner on Nov 11, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 109
Allow for validation failures in the resolve
prop
#57
Comments
peterszerzo
changed the title
Allow for validation failures in the
Allow for validation failures in the Sep 26, 2018
resolve
resolve
prop
I like the idea, I think the simple way to do this is to After we can just set the classic |
The |
I think this can be quite useful! I would +1 this. |
Awesome - shall I go ahead with the implementation? |
Ja |
This was referenced Oct 11, 2018
Merged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
Currently, the
resolve
prop of theGet
component is a simple function that does some transformation on the data coming from the backend. The developer usingrestful-react
is responsible that it is correct (no runtime errors), and add additional logic on their own to handle unexpected responses from the server. In order to offer some legwork to help folks make absolutely sure that the data passing this function either fails gracefully or passes through with sound data, I'd like to suggest two features:fetch
method (adding a.catch
in https://github.com/contiamo/restful-react/blob/master/src/Get.tsx#L152), sending runtime errors to either the global error management of the library, or the local one iflocalErrorsOnly
is enabled. This would help with third-party parsing/validating solutions like https://github.com/jquense/yup#mixedcastvalue-any-any, which are super powerful, but always throw runtime errors when they fail.resolve
prop to accept a promise which either resolves with the correctly shaped data or rejects with an error. Again, this might help with third-party validation solutions which offer some validation features only asynchronously (recursive data structures and the like).Describe alternatives you've considered
I cannot think of an alternative that doesn't bypass
resolve
entirely, leaving validation to be performed inside therender
method and killing performance.Additional context
At a high-level, the purpose of these suggestions is to allow a style of programming that does super-strict validation before data reaches the internals of a react component tree. This provides both safety and debugging convenience: there is always a failure before data even reaches presentational views, narrowing down issues to the validator logic, which can be unit-tested with an ever-broadening list of fixtures from the backend. No more looking around
React
code to fix backend-frontend miscommunication.The text was updated successfully, but these errors were encountered: