What was refactored

Upon inspection of the code left behind. We realised that the application fetching code was hardcoded to always return it grouped by the status column. This worked for the previous group's implementation as they only needed to fetch applications to display on the dashboard, which would need it grouped by status. However, as we wanted to implement more features that could potentially need to retrieve a list of applications we realised that this was a technical debt.

Therefore, the application fetching code was refactored to be broken down into multiple parts. A fetchApplication function that could fetch all applications and return it as a flat list, and then another function used to sort or group the applications as desired (to ensure functionality of legacy code).

In the future, any new feature is able to get a flat list of all applications and then adaptively choose or create any new method to group or sort the applications as desired, making it easier to implement functionality that requires retrieving applications.

Another things we noticed during this refactor was that some information of the application like status and position was not given in the application object, so this was also changed to include such information as it could be useful for newer features.

What this improved

Calendar Page

The calendar page had to sort applications by date, which benefitted a lot from this refactor. With the old implementation, the calendar page would have had to flatten the returned applications first, then sort it again by due date. With the new refactor, it can sort the applications immediately like so:

fetchApplications()
  .then((applications) => {
  if (!cancelled) 
    setItems(groupByDate(applications))
  })