Skip to content

Conversation

@mdanilowicz
Copy link
Contributor

This pull request refactors error handling across multiple account-related components by introducing a centralized apiErrorHandler utility. This change simplifies and standardizes how API errors are processed and displayed to users, replacing repetitive error handling code with a single function call. Additionally, unused imports and functions related to error handling are removed from affected files.

Error Handling Refactor

  • Added new apiErrorHandler utility in utils/validation/rules/errors/apiErrorHandler.ts to handle API errors in a consistent and reusable way across components.
  • Replaced custom error handling logic in form and account components (LoginForm.vue, RegistrationForm.vue, NewsletterBox.vue, index.vue, change-email.vue, change-password.vue, profile/index.vue) with calls to apiErrorHandler, streamlining error display and reducing code duplication. [1] [2] [3] [4] [5] [6] [7]

Cleanup of Imports and Unused Functions

  • Removed unused ApiClientError imports and resolveApiErrors function calls from components where error handling is now delegated to apiErrorHandler. [1] [2] [3] [4]

Minor Code Consistency

  • Adjusted the order of destructuring for pushSuccess and pushError from useNotifications for consistency in LoginForm.vue.

closes #2077

@vercel
Copy link

vercel bot commented Oct 28, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Updated (UTC)
frontends-demo Building Building Preview Oct 28, 2025 7:26am
frontends-vue-starter-template Building Building Preview Oct 28, 2025 7:26am
shopware-frontends-docs Ready Ready Preview Oct 28, 2025 7:26am

Copy link
Contributor

@mkucmus mkucmus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the way it's designed 💙

I wrote some comments to consider, nothing crucial - take a look.

}
}
}
apiErrorHandler(error, "account_login", pushError);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we standardize the context name to be consistent because sometimes it's suffixed by _form and sometimes it's not. maybe we can get rid of the suffix because it's been used only in forms? or other way around - use _form in every form.

Comment on lines +14 to +16
for (const error of errors) {
errorResolver(error);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for (const error of errors) {
errorResolver(error);
}
for (const errorMessage of errors) {
errorResolver(errorMessage);
}

Comment on lines +4 to +7
error: unknown,
context: string,
errorResolver: (error: string) => void,
) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
error: unknown,
context: string,
errorResolver: (error: string) => void,
) {
error: unknown,
context: string,
errorResolver: (error: string) => void,
errorResolverOptions: unknown
) {

then we could pass extra options which for example are available for pushError like so:

errorResolver(errorMessage, errorResolverOptions);

in our useNotifications:

pushError(message: string, options?: NotificationOptions): void;
(NotificationOptions)

Copy link
Contributor

@patzick patzick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid about using composables in until function in regards to sideeffects. I think we could stay within composable and use what we already have, so in useApiErrorsResolver we could add method handleApiError

so for example it would be

const { handleApiError } = useApiErrorsResolver("newsletter_box");

/// ...

} catch(error) {
  handleApiError(error)
}

It would already use existing resolveApiErrors under the hood and also useNotifications + it's in the template to easy to change the behaviour

I really like the fallback if the error is not api, which might happen, now they silently ignored and they should not. I'd even consider console.error in that case

Comment on lines +8 to +11
const { t } = useI18n();

if (error instanceof ApiClientError) {
const { resolveApiErrors } = useApiErrorsResolver(context);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

using composables in a function might cause sideeffects

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[UTILS] Add api error handler

4 participants