Background

In many e-commerce business scenarios, our code often involves lots of logic about calculation and display of the amount.

When taking over a frontend project, I found all the API document has some comments for the amount and percentage-related fields: multiply the actual amount by 100k. After I talk with the backend team, the reason is that Golang has a precision problem when dealing with floating-point numbers. (JavaScript also has)

For reference → https://developpaper.com/golang-has-a-precision-problem-when-dealing-with-floating-point-numbers-if-you-dont-use-decimal-you-will-have-a-big-problem/

As a result, the backend team want to store those amount as an integer, but it should be noted that the accuracy of the amount can only be guaranteed within five decimal places.

I don’t quite agree that is a good practice because:

• It limits the precision of decimals
• Need to convert the processed amount to its actual value when dealing with calculation, for both frontend and backend
• 100k logic of amount and percentage conversion can be confusing

Moreover, this also leads to the following nerve-wracking problems for frontend development:

• The amount needs to be divided by 100k before being displayed on the front end.
• In some forms, when a user is required to fill in the amount to submit, it must be multiplied by 100k before the request is sent.
• For the calculation which involves user input and amount from API response (e.g. calculating price after discount). Part of the equation needs to deal with 100k but others may not.
• …

With the growth of business volume, the scattered 100k logic will become a mess.

Idea

Whether the 100k logic can be concentrated somewhere and process together?

The Axios interceptor seems like a choice. We could focus on the feature code and do the multiplication or division inside the interceptor.