Should we unpack error messages in XState or components? #1961
Closed
presleyp
announced in
Announcements
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
Uh oh!
There was an error while loading. Please reload this page.
-
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