Should we unpack error messages in XState or components?

[presleyp]

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 action assignFooError, which puts the error in context.fooError.

Sometimes, it first checks if the error is an ApiError, and if so, it assumes the error contains an errors array with error messages per form field. But there's another possibility: it's an ApiError that contains just one message.

So I'm proposing: onError, call the action assignFooErrorMessage, unpack the error with getErrorMessage, and put it in context.fooErrorMessage. And if it's form-related, then first check if it hasApiFieldErrors (a function I just wrote), if so unpack with mapApiErrorToFieldErrors instead of unpacking with getErrorMessage.

This would result in eventually changing a lot of our error handling code, but I think it needs an audit anyway.

[BrunoQuaresma]

👍 I like to have this unpacked in the machines instead of the components

[code-asher]

@presleyp test mention

Unpacking in XState sounds ideal to me.

[greyscaled]

This sounds ideal to me as well!

[greyscaled]

@presleyp does the ping send to our Slack integration? This is a (second) test.

[greyscaled]

I wonder if someone replies if I'll see it in Slack as well :O

[presleyp]

@vapurrmaid It doesn't ping Slack. I do get push notifications on my phone though, because I have the GitHub app.

[misskniss]

@presleyp , @bpmct has been working more in Discussions as well. 👍