Could we use the error returned from the response? I think this error commonly might be a duplicate slug, which would be good for merchants to know since it won't resolve itself after a few seconds.

The response is pretty generic and not pretty:

A term with the name provided already exists in this taxonomy

But I think this might still be more useful for merchants to know. cc @jarekmorawski

There are a lot of reasons why I prefer not to show any server error to the final user:

1. Translation
2. Politeness
3. Wrong error handling. What about 500 Internal Server Error or 503 Service Unavailable.
4. Formatting

Also consider that we are not filtering any kind of error given its status code or anything else. So if we show the server error that will mean: show any server error that may occur no matter the reason and the message.
In order to be more specific with the error messages we will need better server responses with particalar kind of error codes that let the frontend understand what should be the right final message to show.

But I think this might still be more useful for merchants to know. cc @jarekmorawski

I agree, but I thought we can't tell what the error is about? 🤔 If we can, it'd make sense to surface it directly within the form, but having spoken with Maikel earlier, we've decided to go with a generic error message. Let me know if there's any wiggle room there. The more specific the error message, the better. 👍

@mdperez86 Those are good concerns. We can probably not worry too much about a couple of them:

Translation

The errors are translated. And because they've been around for a while, are actually more likely new to be translated than our newer frontend strings.

Politeness

While A term with the name provided already exists in this taxonomy does not match the tone of our entire application, this is a common problem throughout Woo right now.

I don't think this message is impolite. It's certainly going to make the user happier knowing how they can solve the issue rather than trying again every few seconds.

Wrong error handling. What about 500 Internal Server Error or 503 Service Unavailable.

Great point. Generally 5xx errors are good candidates for catch-all error messages. 4xx errors like this one should have some information that could prove useful to help the user immediately correct the issue.

If nothing else, more specific error messages help us with debugging down the road.

Formatting

This is a real possibility. Luckily most of the error messages are simply strings, but I've seen some that include links or other small bits of HTML.

In a follow-up, it might be worth us allowing some of this inside the toast notices. We have some sanitization tools that might make this relatively trivial to do.

I agree, but I thought we can't tell what the error is about? 🤔 If we can, it'd make sense to surface it directly within the form

@jarekmorawski we probably can catch this before it's sent to the server, but it does not look like that validation is in place yet.

but having spoken with Maikel earlier, we've decided to go with a generic error message. Let me know if there's any wiggle room there.

I'd really recommend not using a generic error message when we have useful information at our disposal that could immediately help a user solve the issue they're facing. I'd rather display a somewhat poorly formatted error message that would help a user than a pretty one that leaves them confused.

Front-end validation is a good first step in catching issues, but can't and shouldn't be relied on fully. Essentially in this order we should:

1. Front-end validation catches the error before we send it to the server.
2. If the front-end validation fails, display helpful error messages from the server.
3. If the error is a server error that's not helpful with a 5xx code, display a generic error message.

Optionally, at step 2 above, we could write custom error messages for each status type, but this is obviously a lot more work than returning better error messages from the server.

Sounds perfect. I'm happy to write these messages if you can list all possible combinations.

4xx errors like this one should have some information that could prove useful to help the user immediately correct the issue.

Agree, but this phrase A term with the name provided already exists in this taxonomy say nothing to me. To have a good error handling the server should responds with or similar:

{
  "code": 400,
  "errors": [
    { "code": "UNIQUE_SERVER_ERROR_ID", "field": "slug", "message": "Already exists" },
    { "code": "OTHER_UNIQUE_SERVER_ERROR_ID", "field": "name", "message": "Required field" },
  ]
}

Or in case the error is not related to any field in particular

{
  "code": 400,
  "errors": [
    { "code": "UNIQUE_SERVER_ERROR_ID", "message": "A business rule has been violated" },
  ]
}

{
  "code": 500,
  "errors": [
    { "code": "UNIQUE_SERVER_ERROR_ID", "message": "Internal Server Error" },
  ]
}

Server messages should be used for debuging porpose unless a server behaves as a Backend For Frontend (BFF).

Another thing here to remember: we are just working on a MVP. And this a design discussion we should have as a team because whatever be the final point here it should be implemented for the rest of the project. @joshuatf it would be awesome if you lead this discussion with all the team sync or async in order the let them participate in the conversition and in the final decision. What do you think?

Agree, but this phrase A term with the name provided already exists in this taxonomy say nothing to me.

I disagree pretty strongly with this. A term with the name provided already exists in this taxonomy is far more suggestive as to what the error is than We couldn’t add this shipping class. Try again in a few seconds.

Ultimately, we should strive for good user experience. Telling users indefinitely to "Try again in a few seconds" when the issue will not self-resolve is misleading and bad UX.

Server messages should be used for debuging porpose unless a server behaves as a Backend For Frontend (BFF).

Assuming you're just talking about the messages, I agree with this sentiment. But we have codes that can inform the presentation layer what message to add.

Another thing here to remember: we are just working on a MVP. And this a design discussion we should have as a team because whatever be the final point here it should be implemented for the rest of the project.

I'm happy to have this discussion as a team, but I'm not quite sure what the discussion we're having is. We have a fairly easy to hit error and the error message does not tell the user what the error is. If the options are:

a. Catch the fixable error, but give a misleading message to a user
b. Catch the fixable error, tell the user how to fix it

This seems like a no-brainer. I think the amount of time we've spent discussing this could have gone towards adding a few lines to add this error message in.

Love these helper functions!