-
Notifications
You must be signed in to change notification settings - Fork 11
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
Refactor/api service #302
Refactor/api service #302
Conversation
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.
As someone who doesn't write a lot of React/TypeScript, I long for module/class/function docstrings to explain briefly their purpose, but I understand that a lot of this is probably just boilerplate React/TS code and the purpose is very obvious to seasoned developers. 🤷
In the Python world, we encourage and enforce at least minimal inline documentation with ruff
(and previously via flake8-docstrings
), and I know some other mainstream languages have similar encouragement/enforcement tools, but I don't know about JS/TS. Are there standard or common tools we could use here also? As we want to broaden and democratize the ownership and maintenance of quipucords-ui
, I would like to see more inline documentation so that contributors don't have to be (as much) experts in the existing code base.
(I'm not blocking this PR to require docs, but I wanted to put these thoughts somewhere to start a conversation.)
a767316
to
862f1b5
Compare
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 know we did our video code review, but some reminders along with some other things i've noticed going through
536c2dc
to
ddd21d2
Compare
eb848ec
to
54ef5cb
Compare
7860b24
to
da34508
Compare
This Pull Request introduces a refactor aimed at improving the maintainability and scalability of our API interactions within the application. The core changes involve the creation of apiService and ApiHandler. These changes are intended to decouple API calls from page components, enhancing code modularity and readability.
Creation of apiService: Centralizes the API interaction logic, offering a single point of interaction for different API endpoints.
Introduction of ApiHandler: Abstracts common API handling patterns to reduce code duplication and streamline error handling, request sending, and response processing.
Observations:
In some instances, the abstraction provided by ApiHandler did not align perfectly with the specific requirements. These cases have been left as-is for the time being. I am open to suggestions on how to handle these exceptions better.
This refactor focuses on enhancing the maintainability without altering existing functionalities.