Refactors

R1: Firstly, we refactored the way that financial metrics were retrieved within the codebase. In FinancialMetrics.jsx. Metrics were being retrieved and calculated through only the frontend, which added to the loading time of the page; every time the financial metrics were opened, all calculations were made through the React component itself. Ideally, these calculations would be made as an asynchronous method in the backend, to reduce the loading times. This was implemented by creating a new transaction endpoint within the backend.

R2: We refactored TransactionContextProvider.jsx to eliminate unnecessary re-renders that could impact performance. By removing redundant dependencies from the useEffect hook, we reduced re-renders on the frontend, enhancing both performance and code maintainability for future expansions.

R3: We created a new ProgressBar component in src/components/progress-bar/. This change allows for easy reuse with properly defined props, making it simpler to manage and refactor the progress bar functionality as needed. This improves maintainability and facilitates future code enhancements.

R4: We reorganised our folder structure within src/components by creating subfolders for default, Gemini, metrics, progress-bar, transactions, context, pages, and utility. This restructuring has made adding or modifying features throughout the project easier and more robust.

R5: We refactored the data types used in the database. Previously, the transaction used Numeric(10, 2), while the balance and goal were set to double precision. This mismatch could lead to unexpected behaviour. To prevent this, we unified the data types related to monetary values to Numeric(16, 2).

R6: When we received the codebase, front-end styling was done entirely with inline TailWind. While TailWind comes with a multiplicity of advantages over standard CSS, in this specific case it resulted in duplication of styling code across the application. We kept TailWind code where it provided a clear advantage over CSS, however, we created several component-specific CSS files so that styling could be reused across the application, in addition to a variables.css file that enables the use of global variables such that future maintainers can easily change standard colours, gradients, box-shadows, and dimensions from one place.

R7: Originally, code that sets up an instance of the axios object used to interface with the Axios HTTP client API was hard-coded into every instance of its use. This unnecessary repetition of code meant that if values such as the server address are to be changed the entire codebase must be thoroughly investigated to ensure that the change is reflected consistently. We created an axiosUtil.jsx file that features a function which returns a consistent axios object.

R8: Code duplication also existed with currency conversion features. A currency.jsx file was produced which contains a suite of features relevant to the support of multiple currencies. Different modules of the application require access to currency conversion at different levels, from calling the start-to-finish refresh of the user’s balance in the selected currency, to accessing currency exchange rates directly. To address this, each currency conversion function is built atop the last to create a comprehensive family of functions that can be as abstract as the context requires. Additionally, a dictionary of currency symbols was recorded in transactionContext.jsx so that currencies can be easily added or removed in on place.