Replies: 2 comments 6 replies
-
π I like to have this unpacked in the machines instead of the components |
Beta Was this translation helpful? Give feedback.
6 replies
-
@presleyp , @bpmct has been working more in Discussions as well. π |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is a small question but I thought I'd use it as a chance to find out how GitHub discussions work. Maybe they'll work better than issues for decision-making?
I want to unpack error messages from errors in XServices instead of in components, because a) I don't think components should have to know what our API returns and b) I don't want to keep
unknown
types around any longer than necessary.So currently our XServices have a lot of stuff like:
onError
, call the actionassignFooError
, which puts the error incontext.fooError
.Sometimes, it first checks if the error is an
ApiError
, and if so, it assumes the error contains anerrors
array with error messages per form field. But there's another possibility: it's anApiError
that contains just onemessage
.So I'm proposing:
onError
, call the actionassignFooErrorMessage
, unpack the error withgetErrorMessage
, and put it incontext.fooErrorMessage
. And if it's form-related, then first check if ithasApiFieldErrors
(a function I just wrote), if so unpack withmapApiErrorToFieldErrors
instead of unpacking withgetErrorMessage
.This would result in eventually changing a lot of our error handling code, but I think it needs an audit anyway.
Beta Was this translation helpful? Give feedback.
All reactions