-
Notifications
You must be signed in to change notification settings - Fork 78
feat(vue-starter-template): api error handler util #2094
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this 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); |
There was a problem hiding this comment.
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.
| for (const error of errors) { | ||
| errorResolver(error); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| for (const error of errors) { | |
| errorResolver(error); | |
| } | |
| for (const errorMessage of errors) { | |
| errorResolver(errorMessage); | |
| } |
| error: unknown, | ||
| context: string, | ||
| errorResolver: (error: string) => void, | ||
| ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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; |
There was a problem hiding this 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
| const { t } = useI18n(); | ||
|
|
||
| if (error instanceof ApiClientError) { | ||
| const { resolveApiErrors } = useApiErrorsResolver(context); |
There was a problem hiding this comment.
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
This pull request refactors error handling across multiple account-related components by introducing a centralized
apiErrorHandlerutility. 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
apiErrorHandlerutility inutils/validation/rules/errors/apiErrorHandler.tsto handle API errors in a consistent and reusable way across components.LoginForm.vue,RegistrationForm.vue,NewsletterBox.vue,index.vue,change-email.vue,change-password.vue,profile/index.vue) with calls toapiErrorHandler, streamlining error display and reducing code duplication. [1] [2] [3] [4] [5] [6] [7]Cleanup of Imports and Unused Functions
ApiClientErrorimports andresolveApiErrorsfunction calls from components where error handling is now delegated toapiErrorHandler. [1] [2] [3] [4]Minor Code Consistency
pushSuccessandpushErrorfromuseNotificationsfor consistency inLoginForm.vue.closes #2077