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
It seems like the various createFooError(errorMessage)s and the various upstream handlers all expect errorMessage to be a string. If my API returns a map instead we get [object Object].
In the other ticket I filed, I post a solution for preprocessing the error message into a string. However, I was wondering if it's reasonable to just check for stringiness in this library, and call JSON.serialize on the message if it's not a string?
Seems related to #20 and #29. Also related to phoenixframework/phoenix#3323.
It seems like the various
createFooError(errorMessage)
s and the various upstream handlers all expecterrorMessage
to be a string. If my API returns a map instead we get[object Object]
.In the other ticket I filed, I post a solution for preprocessing the error message into a string. However, I was wondering if it's reasonable to just check for stringiness in this library, and call
JSON.serialize
on the message if it's not a string?A simple example would be changing
createRequestError()
to be:(Would obviously benefit from more abstraction!)
The text was updated successfully, but these errors were encountered: