Home

The api-client is a dart package used by the weekplanner application. The responsibility of the package is to provide http request functionality to the frontend, thereby facilitating the communication between frontend and backend. In addition to handling requests it also represents the response in a way the frontend can understand and utilize.

Pull-requests

For this repository pull-requests are created whenever a feature needs to be merged with the develop-branch. For each pull-request you will need two people from your semester to approve your code.

These reviewers will be added automatically if you followed this Github setup guide

If you wanna learn more general information about pull-requests and issues please see the following guide: Github setup guide

Creation

When creating a pull-request it will by default use the PR-template in the .github repository. Inorder to make it easier for the reviewers to see what you created, please fill out the template.

For ease please link the concerned issue in the "fixes"-mark in the template

If you wish to edit the default template it can be found here: PR template

Review

When reviewing a pull-request please copy the following review-template into a comment in the pull-request, and use it as a guideline to whether or not you should approve a given pull-request.

PR review template

## Code
### Code Design

- [ ] The code is in the right place? (Both in terms of folder structure and class structure)
- [ ] The code is not over-engineered. Examples of over-engineering: Implemented behavior for future problems     
- [ ] This code could not, to the best of my knowledge, have reused existing code
- [ ] The code does not introduce functionality that is unnecessary for solving the problem

### Code Readability

- [ ] Names are meaningful and self-documenting
- [ ] It is understandable, by reading the code, what it does
- [ ] The code is simple and readable. i.e. it contains no \"hack\", or obscure solution   

### Code Maintainability

- [ ] Has all the added code been properly commented

**Only check one of the items below:**

- [ ] The functionality does **not** need to be covered by tests
- [ ] The functionality needs to be covered by tests


**Only check these if the functionality needs to be covered by tests:**

- [ ] All functionality is covered by tests
- [ ] The tests has sensible names
- [ ] By reading the tests you know what they cover
- [ ] The tests cover sensible cases. Both happy paths and exception paths
- [ ] The tests cover the full functionality. i.e., The tests fails if some of the requested functionality is missing