Pass more data to FetchError to handle API errors in admin forms

[ochicf]

Context

Currently FetchError is thrown for non success HTTP statuses, but little information is provided alongside it. See:

medusa/packages/core/js-sdk/src/client.ts

Line 84 in 4ea1a2e

throw new FetchError(

In the project code, there's no way of knowing the specific error of the API request, as only message, status and statusText ara available.

Proposal

I think it would be nice that it accepts more data, so there's more context about the error when handling it. Potential use cases:

• returning zod issues when validating in the BE, that could be retrieved on the FE to map those errors to form fields
• returning field more data for certain exceptions, such as duplicated data, to know which field is the one that triggered the error

The simplest implementation would be to pass the original response instance to the error so it can be accessed in the error handler. This would prevent the client to take any part of extracting the payload, it would be deferred to the handler.

Example

Example of implementation (code in Medusa SDK)

• update FetchError to accept extra parameter in constructor

export class FetchError extends Error {
  status: number | undefined
  statusText: string | undefined
  data: object | undefined

  constructor(message: string, statusText?: string, status?: number, data?: object) {
    super(message)
    this.statusText = statusText
    this.status = status
    this.data = data
  }
}

• throw by passing the json error object

throw new FetchError(
  jsonError.message ?? resp.statusText,
  resp.statusText,
  resp.status,
  jsonError
)

Example of usage (code in Medusa projects)

• catch error when performing a mutation

const handleSubmit = form.handleSubmit(async (values) => {
  await entityCreateMutation
    .mutateAsync({
      body: values,
    })
    .then(({ data }) => {
      toast.success("Entity created successfully");
      return handleSuccess(`/entities/${data.handle}`);
    })
    .catch(async (error: FetchError) => {
      toast.error("Failed to create entity");
      await setFetchErrorsInForm(form, error?.response);
    });
});

• potential mapping of errors from API response to form errors (example implementation, not fully tested):

const mapFormErrors = <Form extends UseFormReturn<UntypedValue>>(
  form: Form,
  errors: z.ZodIssue[]
) => {
  const mappedErrors = errors.reduce((acc, error) => {
    const fieldName = error.path.join(".");
    const fieldValue = get(form.getValues(), fieldName);
    if (typeof fieldValue === "undefined") {
      return acc;
    }
    acc[fieldName] = error;
    return acc;
  }, {} as Record<keyof Form["getValues"], z.ZodIssue>);

  return mappedErrors;
};

const setFetchErrorsInForm = <Form extends UseFormReturn<any>>(
  form: Form,
  error: FetchError
) => {
  if (error?.status === 400) {
    const errors =
      error.data && "errors" in error.data && Array.isArray(error.data.errors)
        ? error.data.errors as z.ZodIssue[]
        : [];
    const mappedErrors = mapFormErrors(errors);
    Object.keys(mappedErrors).forEach((key) => {
      const error = mappedErrors[key];
      const fieldName = key as keyof Form["getValues"] & string;
      form.setError(fieldName, { message: error.message });
    });
  }
};

Discussion topics

1. would this be useful to anyone?
2. what do you think about the proposed interface?
3. as a follow-up, would it make sense to allow adding extra payload when creating a MedusaError so it could be also accessible in the FE?