Tong Hin's Blog

Monday, August 25, 2025 – Last week, I was assigned a new task, to build the final feature for the Next.js project. Alongside that, I was also introduced to a second task, which I’ll begin once the first one is completed.

While waiting for the API for my first task to be ready, I took the opportunity to work on creating a command API as a kickstart. This gave me a clearer vision of what to expect and how the flow should look. During this time, Mr. Peter also explained the objectives in more detail and answered my questions, which really helped me see the bigger picture of the project’s direction.

Once the API was ready, I returned to my first task. I started with the main page, which displays the list, and then moved on to the create and edit pages. My main focus was ensuring the “create” function worked smoothly. By the end of the week, I had completed the create page, though it wasn’t fully successful yet. That will be my main priority to refine and finalize this week.

Monday, August 18, 2025 – Last week, I continued working on the feature. With the event-triggering issue resolved, the update command could finally be called correctly. I then focused on implementing the calculation logic, which was the core functionality of the feature.

After updating the command API with the correct logic, I created controller tests to verify everything was working properly. When I demonstrated the progress to Mr. Peter, it turned out I had misunderstood part of the logic flow. I clarified the requirements with him to ensure I had the right understanding moving forward.

By the end of the week, I managed to complete the feature, although I still plan to conduct more thorough testing. I pushed all my changes, and Mr. Peter also explained the upcoming tasks I’ll be working on next week.

Monday, August 11, 2025 – Last week, I was assigned a new feature by Mr. Peter. The goal was to design a UI similar to Excel, where users could freely edit cells, and moving to the next cell would automatically save changes. Additionally, certain fields needed to be auto-calculated based on the updates.

To start, I created a simple get list UI, which was fairly straightforward. Afterward, I moved on to the UI portion, focusing on building a simple display list.

Next, I worked on an update command so that users could update data line by line instead of saving the entire list at once. This approach would be faster, but at first, I skipped adding the full calculation logic and only tested the basic command. I then integrated the UI with the update command. Unfortunately, it didn’t work as expected, the event wasn’t being triggered.

Towards the end of the week, Mr. Peter helped me identify the issue. It turned out there was a small mistake in the naming convention within the UI, which I had overlooked. Once corrected, the update event worked as intended.

Monday, August 4, 2025 – Last week, I couldn’t complete the UI for the latest feature I was developing. Since it was urgent and needed to be published quickly, Mr. Peter took over and finished it.

Meanwhile, a UI bug was discovered with button positioning on a feature I had previously worked on, the button was hidden on smaller screen sizes. I fixed the issue immediately and pushed my latest changes.

By the end of the week, I focused on testing and fixing several minor bugs across different features to ensure stability. I also received a new feature assignment from Mr. Peter, who explained the requirements in detail. I plan to begin working on this task in the coming week.

Monday, July 28, 2025 – Last week, I worked on a new task for the Nextjs project, where I was assigned to create a new UI page for a feature. Since the feature was quite similar to an existing system, the design process was straightforward and easy to implement.

Once the UI was completed, I immediately tested it. At first, there were minor bugs after sending the command. When the API was fixed, I tested again, but this time, nothing appeared in the progress section. Later, Mr. Peter helped by creating a progress bar helper and fixing the current logic of the progress bar, which resolved the issue.

Another small task I worked on was adding a SortBy filter in a different project. I began by building the UI logic and implementing enumeration for it. However, towards the end of the week, although the main feature was up and running, I was not able to finish the SortBy UI. Still, I pushed all my changes for review.

Monday, July 21, 2025 – Last week, I continued my work by implementing the in-memory cache for the query I built earlier. I started by drafting an initial structure based on what Mr. Peter previously explained. Later, he provided an example using Microsoft’s IDistributedCache.

To avoid repeating cache logic across the codebase, I encapsulated the caching functionality into a reusable cache service. This service allows caching data by simply passing a unique key and the data list. The data is serialized and stored in memory. To retrieve the cache, we just pass the same key.

I also implemented a time-based expiration using DistributedCacheEntryOptions, so that cached items are automatically removed after a set duration. However, as Mr. Peter pointed out, we must also guard against unbounded cache growth. So I added a cache size limit to prevent excessive memory usage.

To handle cases where the cache reaches its size limit, I implemented a cache eviction policy to remove the oldest entry before adding a new one. Since standard in-memory cache doesn’t track insertion order, I built a registry system to track the order of cached items. This registry makes it possible to identify and remove the oldest entry when needed.

By the end of the week, I had fully implemented the caching system. The last remaining task was to ensure that all related cache entries are cleared when the underlying data changes (specifically when the quantity of a cached entity is updated). I created a method to clear all relevant caches and, with Mr. Peter’s help, integrated this method into the necessary update flows.

Monday, July 14, 2025 – Last week, I was assigned to build a new API query for an existing UI. Previously, the UI directly accessed the repository without going through an API layer. To improve separation of concerns and promote loose coupling, I was tasked to create an API query so that the UI now communicates with a proper API endpoint instead of directly interacting with the repository. This helps enforce dependency inversion, where the higher-level UI module no longer depends on lower-level data modules directly, but instead communicates through defined interfaces (API).

In addition to creating the new query, I was also tasked with implementing caching for this API but without using Redis. Instead, I would need to use in-memory caching. Before tackling the cache, I focused on completing the query.

One key difference with this new query is that it pulls two separate item lists from two different databases, yet still returns them in a single response. Despite the difference, the implementation remained relatively straightforward.

Once the query was complete, I wrote a simple test and moved on to the next task: implementing the UI. I followed the previous design pattern with one main difference. Previously, the system used two separate views merged into one page. However, since the new query provides both lists in one call, only one view and one view model were needed. This change helped simplify the UI structure.

By the end of the week, I had completed the UI. However, more testing and refinement are still needed, especially since this UI will be reused in multiple features. I also need to finalize the caching mechanism, which I plan to continue next week.

Monday, June 23, 2025 – My first task last week was to update and rearrange the UI for the a printing feature in the Next.js project. After discussing the expected result with Mr. Peter, I immediately began working on the UI changes. I started by changing the layout from vertical to horizontal to reduce unnecessary scrolling for the user. Then, I refined each section individually, adjusting styles to make the design appear cleaner and more user-friendly, without altering the core logic. Once the UI updates were complete, I conducted thorough testing to ensure everything worked without bugs.

After completing that, I moved on to another task: adding new UI filters to reflect the updated API list queries. These included additional query parameters. After implementing one feature, I carefully verified all other related features to make sure no API query properties were missed. Missing such updates could trigger errors, making this a critical step.

Later in the week, I was assigned a new task, creating a hosted service to update MongoDB whenever changes were made in the main system. Mr. Peter guided me through the intended logic and even provided examples. I rushed to complete the implementation before the week ended. Although I managed to finish writing the code, I didn’t get a chance to properly test the logic or notify the team before pushing my changes.

Monday, July 7, 2025 – Last week, I conducted thorough testing on the Next.js project to identify and resolve as many unhandled errors and bugs as possible. Several minor issues were uncovered, and I worked swiftly to address each one before moving on to the next.

One notable bug occurred on the detail view page, where an image viewing feature was integrated. If the image size extended to half the height of the page, the top and bottom parts of the image became hidden. Fortunately, this bug was found as it would be a critical bug since user won’t be able to close the page. Thankfully this was an easy fix, by enabling scroll on the page and making minor layout adjustments, the issue was resolved.

Another more intriguing bug appeared on the entity number adjustment page. When a user entered a value into the final input field and pressed “Enter,” a confirmation dialog was expected to appear. However, pressing “Enter” on one of the dialog buttons did not trigger any action, unless it was pressed twice. After investigating, I discovered that the issue stemmed from the main page using ref.focus, which interfered with the alert dialog’s focus.

To resolve this, I introduced a useState variable to track whether the focus was currently on the alert dialog or the main page. Additionally, I enhanced the GeneralAlert component to automatically focus the primary action button when the alert appears. These changes successfully resolved the issue.

Towards the end of the week, I was assigned an interesting new task, which I look forward to continuing this week.

Monday, June 30, 2025 – My first task last week was to add a new feature to the Next.js project, a UI page for exporting data. I began by designing the UI, which included a date range selector (start and end dates) and buttons necessary for triggering data export. Once the UI layout was polished, I tested the date picker and buttons to ensure they worked as expected.

One of the main goals for this page was to allow users to choose a local folder where exported files would be saved. Initially, I was able to trigger the folder picker popup successfully. However, selecting a folder consistently threw errors. Upon further investigation, I discovered that while this functionality works on desktop applications, browsers restrict access to full file paths (e.g., C:/exports) for security and privacy reasons. Instead, APIs like showDirectoryPicker() only provide a secure handle to the selected folder without revealing its actual path. Due to these browser limitations, the original objective couldn’t be achieved. As a workaround, I adjusted the functionality so users only need to click one button, and the exported file will automatically download to their default Downloads folder.