26 lines
1.7 KiB
Markdown
26 lines
1.7 KiB
Markdown
# Refactoring Plan for backend/internal/api/handlers
|
|
|
|
## Goal
|
|
|
|
Refactor the code in `backend/internal/api/handlers` to reduce repetition and create helper functions for boilerplate operations, utilizing functions from `backend/internal/api/utils/handler_utils.go` and creating new ones if necessary.
|
|
|
|
## Analysis
|
|
|
|
The following common patterns were identified in the handler files:
|
|
|
|
1. **Error Handling:** Each handler function repeats the same error handling pattern.
|
|
2. **DTO Binding:** Parsing the request body and handling potential errors.
|
|
3. **ID Parsing:** Parsing the ID from the URL and handling potential errors.
|
|
4. **DTO Conversion:** Converting between DTOs and models.
|
|
5. **Success Responses:** Calling `responses.SuccessResponse` with the appropriate HTTP status code and data.
|
|
6. **Not Found Responses:** Checking if a record exists and calling `responses.NotFoundResponse` if it doesn't.
|
|
|
|
The `Update` handler is the most complex and has the most potential for refactoring.
|
|
|
|
## Plan
|
|
|
|
1. **Implement a generic `HandleUpdate` function in `handler_utils.go`:** This function will encapsulate the common logic for updating entities, including parsing the ID, binding the JSON, converting the DTO to a model, calling the update function, and handling errors and not found cases. The function will also handle nullable fields correctly.
|
|
2. **Modify the existing handlers to use the new `HandleUpdate` function:** This will involve removing the duplicated code from each handler and calling the generic function instead.
|
|
3. **Create new helper functions in `handler_utils.go` if needed:** If there are any specific operations that are not covered by the existing utility functions, I will create new ones to handle them.
|
|
|