Skip to content

Commit

Permalink
#doc Chores: Fix typo
Browse files Browse the repository at this point in the history
  • Loading branch information
@wangc9
wangc9 committed Jan 31, 2024
1 parent 847a742 commit 486d18f
Show file tree
Hide file tree
Showing 2 changed files with 29 additions and 29 deletions.
30 changes: 15 additions & 15 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@
<li><a href="#roadmap">Roadmap</a></li>
<li><a href="#license">License</a></li>
<li><a href="#contact">Contact</a></li>
<li><a href="#acknowledgments">Acknowledgments</a></li>
<li><a href="#acknowledgements">Acknowledgements</a></li>
</ol>
</details>

Expand All @@ -52,12 +52,12 @@

![Delivery fee calculator](./src/assets/front-page.png)

This is a simplified delivery fee calculator. User can type in the value of products, the distance of the delivery, the total number of products, and finally the favourable order time, to calculate the fee for delivering all the products. Users also have the chance to change the data if needed before calculating the final fees.
This is a simplified delivery fee calculator. Users can type in the value of products, the distance of the delivery, the total number of products, and finally the favourable order time, to calculate the fee for delivering all the products. Users also have the chance to change the data if needed before calculating the final fees.

The calculator follows the following rules when calculating the fee:

- If the cart value is less than 10€, the difference between cart value and 10€ is added as surcharge.
- All orders within 1000 meters are charged a basic delivery fee of 2€. An additional 1€ is charged for every additional 500 meters. Additional distance less than 500 meters is rounded **up** and counted as full 500 meters.
- If the cart value is less than 10€, the difference between the cart value and 10€ is added as a surcharge.
- All orders within 1000 meters are charged a basic delivery fee of 2€. An additional 1€ is charged for every additional 500 meters. Additional distances less than 500 meters are rounded **up** and counted as full 500 meters.
- If there are five or more items, each item above and including the fifth one is charged 50 cents. If the total number of items is more than 12, a separate 1,2€ is charged in addition to the surcharge for each item.
- For orders whose order time is between 3 p.m. and 7 p.m. on Friday, the total fee is multiplied by 1.2.
- The maximum possible delivery fee is 15€.
Expand All @@ -67,7 +67,7 @@ When first loaded, the user is prompted to the front page to type in information

After clicking the submit button, the user is prompted to confirm the input or cancel and re-enter the information.![confirm input](./src/assets/confirm.png)

If user choose to confirm the order, a new page will show up with the confirmed information and the final delivery fee. User can then choose to return to the front page by pressing the return button.![result page](./src/assets/result.png)
If the user chooses to confirm the order, a new page will show up with the confirmed information and the final delivery fee. The user can then choose to return to the front page by pressing the return button.![result page](./src/assets/result.png)

<p align="right">(<a href="#readme-top">back to top</a>)</p>

Expand All @@ -94,18 +94,18 @@ If user choose to confirm the order, a new page will show up with the confirmed
<!-- GETTING STARTED -->
## Getting Started

This frontend is deployed on [Render](https://delivery-fee-calculator-cx83.onrender.com). **Note: The website is deployed using a free CPU thus it will take some time for the page to load!** However, you could still try it locally. There are two options to deploy the project locally. You can use the Docker image provided in this project. It is also possible to try out the project without Docker. This project follows the Test-driven Development ([TDD](http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd)) practice. There are different types of tests in the project. Detailed instructions on how to run them are provided later.
This project is deployed on [Render](https://delivery-fee-calculator-cx83.onrender.com). **Note: The website is deployed using a free CPU thus it will take some time for the page to load!** However, you could still try it locally. There are two options to deploy the project locally. You can use the Docker image provided in this project. It is also possible to try out the project without Docker. This project follows the Test-driven Development ([TDD](http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd)) practice. There are different types of tests in the project. Detailed instructions on how to run them are provided later.

### Prerequisites

In order to run this project locally, Node.js is needed. Please have a look at the [official website](https://nodejs.org/en/download) and install the latest LTS version Node 20. The Docker file provided has Node configured. Therefore, if you choose to use Docker, it is required that you have docker additionally installed on your machine. To install Docker, please have a look at the official installation guide at [Get Docker](https://docs.docker.com/get-docker/).
In order to run this project locally, Node.js is needed. Please have a look at the [official website](https://nodejs.org/en/download) and install the latest LTS version Node 20. The Docker file provided has Node configured. Therefore, if you choose to use Docker, it is required that you have Docker additionally installed on your machine. To install Docker, please have a look at the official installation guide at [Get Docker](https://docs.docker.com/get-docker/).


### Installation

#### Using Docker

1. Make sure that you have successfully installed Docker on your machine and it can work properly. If this is not possible, please skip to <a href="#using-own-machine">Using own machine</a>.
1. Make sure that you have successfully installed Docker on your machine and that it can work properly. If this is not possible, please skip to <a href="#using-own-machine">Using own machine</a>.

2. At the root directory, run the following command to start the web page
```sh
Expand Down Expand Up @@ -149,7 +149,7 @@ In order to run this project locally, Node.js is needed. Please have a look at t
```sh
npm start
```
You should see something similar like this in your terminal:
You should see something similar to this in your terminal:
>VITE v5.0.12
>
>->Local: http://localhost:5173
Expand All @@ -176,7 +176,7 @@ In order to run this project locally, Node.js is needed. Please have a look at t
```sh
npm install
```
if hasn't been done before to install all packages needed
if hasn't been done before to install all the packages needed

2. Start the webpage according to the method chosen.

Expand All @@ -191,7 +191,7 @@ In order to run this project locally, Node.js is needed. Please have a look at t
```
**Make sure that the webpage is actually running before moving on to the next step**

3. If you prefer to use an UI for the e2e tests, in a new terminal at the root directory, run
3. If you prefer to use a UI for the e2e tests, in a new terminal at the root directory, run

```sh
npm run cypress:open
Expand All @@ -214,7 +214,7 @@ In order to run this project locally, Node.js is needed. Please have a look at t
<!-- ROADMAP -->
## Roadmap

See the [change log](./CHANGELOG.md) for a full list changes.
See the [change log](./CHANGELOG.md) for a full list of changes.

See the [reflection](./REFLECTION.md) for a reflection on the project, including technology choices, experience, and possible improvements.

Expand All @@ -240,10 +240,10 @@ Chen Wang - [wang.756090@gmail.com](wang.756090@gmail.com)



<!-- ACKNOWLEDGMENTS -->
## Acknowledgments
<!-- ACKNOWLEDGEMENTS -->
## Acknowledgements

* This project uses material provided in Wolt's [media kit](https://press.wolt.com/en-WW/media_kits/225299/).
* This project uses the material provided in Wolt's [media kit](https://press.wolt.com/en-WW/media_kits/225299/).
<p align="right">(<a href="#readme-top">back to top</a>)</p>
Expand Down
28 changes: 14 additions & 14 deletions REFLECTION.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,54 +6,54 @@ This is a personal reflection on the project, the choice of libraries or tools u

### TypeScript, React and Vite

I choose Vite as the build tool for the project because it is relatively easy to use and require minimum configuration. With the official [Redux TS template for Vite](https://github.com/reduxjs/redux-templates), it was quite simple to get head start with the configuration. Although during the project, I did get into problem with the configuration of Vite when using Docker, the general experience was quite smooth. I previously ran into trouble with testing using Vite and Jest, fortunately this hasn't happened in the project.
I chose Vite as the build tool for the project because it is relatively easy to use and requires minimum configuration. With the official [Redux TS template for Vite](https://github.com/reduxjs/redux-templates), it was quite simple to get a head start with the configuration. Although during the project, I did get into a problem with the configuration of Vite when using Docker, the general experience was quite smooth. I previously ran into trouble with testing using Vite and Jest, fortunately this hasn't happened in the project.

### Redux

Redux is my go-to state management library. This project also has just the correct size and use case for the library. In the "form" or front page, there are four inputs. Each of them needs to remember the user's input. Using React's useState could be an option but it might means prop drilling or having to put all four inputs in one file. This makes Redux a good option.
Redux is my go-to state management library. This project also has just the correct size and use case for the library. In the "form" or front page, there are four inputs. Each of them needs to remember the user's input. Using React's useState could be an option but it might mean prop drilling or having to put all four inputs in one file. This makes Redux a good option.

### Material UI

For CSS library, I used Material UI because the project doesn't really require that many customisations. I've already used Material UI a lot before, so using it in the project feels familiar and *relatively* comfortable.
For the CSS library, I used Material UI because the project doesn't really require that many customisations. I've already used Material UI a lot before, so using it in the project feels familiar and *relatively* comfortable.

### ESlint and Prettier

This is really easy to justify. They are the most popular tools for code quality check. I choose to follow the Airbnb guide which in my opinion is quite comprehensive, although I've also found some arguments against using it as it might be an overkill for small projects. I'm very eager to learn about how Wolt ensures code format.
This is really easy to justify. They are the most popular tools for code quality checks. I choose to follow the Airbnb guide which in my opinion is quite comprehensive, although I've also found some arguments against using it as it might be an overkill for small projects. I'm very eager to learn about how Wolt ensures code format.

### Jest, React testing library, and Cypress

These three tools form a good combination to perform different level of tests in my opinion. I've used jest for unit tests of redux, react testing library for unit tests and integration tests of various components and pages, and finally Cypress for e2e tests. Personally, I think the test cases have basically covered all scenarios that are common for the project, but I think I still have a long way to go to write better automated tests.
These three tools form a good combination to perform different levels of tests in my opinion. I've used jest for unit tests of redux, react testing library for unit tests and integration tests of various components and pages, and finally Cypress for e2e tests. Personally, I think the test cases have basically covered all scenarios that are common for the project, but I think I still have a long way to go to write better automated tests.

### React routers

This was used in a very small fraction of the project just to separate the input page and result page in different routes. It is just a small add-on for the project which follow some basic logic that the result needs to be on a separate page to be more intuitive for users.
This was used in a very small fraction of the project just to separate the input page and result page in different routes. It is just a small add-on for the project which follows some basic logic that the result needs to be on a separate page to be more intuitive for users.

### Docker

This is the first time I've tried to use Docker throughout the development. I've always wanted to try Docker on a larger scale and this project seems to be in the right size. Of course I've run into some problems when doing it, but I'm glad that I've learnt a lot from it.
This is the first time I've tried to use Docker throughout the development. I've always wanted to try Docker on a larger scale and this project seems to be in the right size. Of course, I've run into some problems when doing it, but I'm glad that I've learnt a lot from it.

### GitHub Actions

I'm familiar with using GitHub Actions and it has become kind of a muscle memory for me. I'm glad that I've used it as it has helped me spotted some problems with code format and e2e testing.
I'm familiar with using GitHub Actions and it has become kind of a muscle memory for me. I'm glad that I've used it as it has helped me spot some problems with code format and e2e testing.

## What I've learnt

* **More about test-driven development**. In this project, I've tried to use the three levels of tests to compensate each other and test different functions, components, and scenarios. It is time-consuming, but also quite rewarding. I used to be confused between unit test and integration test as their boundary can be blur sometimes. In this project, I tried to force myself to distinguish them, and I think I have a better grip on them than before.
* **More about test-driven development**. In this project, I've tried to use the three levels of tests to compensate for each other and test different functions, components, and scenarios. It is time-consuming, but also quite rewarding. I used to be confused between unit tests and integration tests as their boundary can be blurry sometimes. In this project, I tried to force myself to distinguish them, and I think I have a better grip on them than before.

* **More about Docker**. I've learnt a lot about the use of Docker in development through try-and-error. And I'm surprised to know that Docker is not the firm guarantee that the program inside will always work. There's definitely place for me improve when it comes to using Docker better.
* **More about Docker**. I've learnt a lot about the use of Docker in development through try-and-error. And I'm surprised to know that Docker is not a firm guarantee that the program inside will always work. There's definitely space for me to improve when it comes to using Docker better.

* **More about accessibility**. I've used the [IBM Equal Access Accessibility Checker](https://chromewebstore.google.com/detail/ibm-equal-access-accessib/lkcagbfjnkomcinoddgooolagloogehp) to check the accessibility of the project, and I've learnt a lot from the rules and suggestions, such as the use of `<fieldset>`, labels and correct contrast ratio. This is also the first time I've tried to view a webpage under high-contrast mode.

## What could be improved

* **Better tests**. When designing the tests, I followed my own "rule" that each component should have its own tests and e2e tests should act as a comprehensive guard for the whole app. This results in a somewhat even distribution between the three level of tests, which works but is time-consuming. In addition, I've only included a handful of test cases. Having more of them and maybe include some more edge cases will definitely help me "sleep better at night". Moving on, I would like to put more emphasis on lower-level tests, and I would really love to know about how Wolt designs tests to have more unit tests, less integration tests and even fewer e2e tests.
* **Better tests**. When designing the tests, I followed my own "rule" that each component should have its own tests and e2e tests should act as a comprehensive guard for the whole app. This results in a somewhat even distribution between the three levels of tests, which works but is time-consuming. In addition, I've only included a handful of test cases. Having more of them and maybe including some more edge cases will definitely help me "sleep better at night". Moving on, I would like to put more emphasis on lower-level tests, and I would really love to know about how Wolt designs tests to have more unit tests, fewer integration tests and even fewer e2e tests.

* **Use customised CSS library**. While using Material UI was quite easy, it has its own trade-off: less customisation and harder to test. The latter is especially true, as I had a hard time trying to analyse what each Material UI component actually contains and how can I put the `data-test-id` into the right component. Using pure CSS or TailwindCSS could be an alternative.

* **Improve Docker**. In this project, I didn't include Cypress in the development docker, so the e2e tests need to be run outside of Docker. This is not the optimal solution. Moving on, I'd like to explore Cypress's official docker image and use them instead to integrate e2e tests.
* **Improve Docker**. In this project, I didn't include Cypress in Docker, so the e2e tests need to be run outside of Docker. This is not the optimal solution. Moving on, I'd like to explore Cypress's official docker image and use it instead to integrate e2e tests.

* **Better documentation**. I've tried to follow the guideline of [TSDoc](https://tsdoc.org/) when writing comments for the code. But I still feel like there are spaces for improvement.
* **Better documentation**. I've tried to follow the guidelines of [TSDoc](https://tsdoc.org/) when writing comments for the code. But I still feel like there are spaces for improvement.

## Summary

This has been a really fun project for me, and I have had the opportunity to close some gaps of my knowledge. Hopefully this reflection has provided good insight and I am really eager to have a deeper discussion on the project. Thank you for reading.
This has been a really fun project for me, and I have had the opportunity to close some gaps in my knowledge. Hopefully, this reflection has provided good insight and I am really eager to have a deeper discussion on the project. Thank you for reading.

0 comments on commit 486d18f

Please sign in to comment.