Repository navigation
Refactoring
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 thing we noticed during this refactor was that some information of the application like status and position were not given in the application object, so this was also changed to include such information as it could be useful for newer features.
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))
})Where groupByDate() is a function that sorts the flat list by application due date. Before the refactor, there would have been another function before this one that flattened the fetched applications, slowing it down.
When implementing the Tasklist Page, the refactoring highlighted the importance of separating data retrieval from how data is displayed. Although the Task List uses a separate database table, the Tasklist Page followed a similar approach by separating Supabase operations from the frontend components.
This was particularly useful when implementing the Due Soon column. Unlike the other three columns, which group tasks by status, Due Soon needs to display tasks from multiple statuses based on their due dates. By keeping this calculation separate from the database operations, we could reuse the tasks already fetched and filter them without requiring another Supabase query.
This separation also made the Task List easier to maintain, as changes to how tasks are displayed do not necessarily require changes to how they are retrieved or stored.