Category: Experiential

Monday, April 7 2025 – Over the past few weeks, I’ve been working on several features that are part of a larger parent module, the transfer process. This includes building pages for creating transfer orders, picking and packing, delivery, and receiving. Last week, I successfully completed end-to-end testing of the entire flow, ensuring that everything functions smoothly from start to finish.

Through this testing phase, I was able to identify several bugs and issues. Whenever I encountered an error, I took the time to trace its source, whether it originated from the UI or the backend. I made it a habit to document every bug I came across and performed stress testing by intentionally trying to “break” the page. For example, I repeatedly switched between view and edit modes to confirm that the state transitions were handled correctly in the code. I also tested actions like creating and canceling, undoing and redoing, and made sure to resolve all errors thrown by React.

In addition to that, Mr. Peter recently assigned me a new daily task. Starting last week, I’ve been dedicating the last two hours of my workday to this task. It involves uploading item information into the system, and also includes editing item images. Since the image editing part requires Photoshop, Mr. Peter gave me a walkthrough on how to do it. I’m still adjusting to the image editing process, but I’m committed to learning and doing my best.

Monday, March 24 2025 –Last week, I focused on resolving several UI bugs based on the latest findings. While addressing these issues, I also identified and implemented necessary improvements.

The first task was to create a new dropdown component that displays a list of all stores. This dropdown was required for features that had recently been developed, making it essential to have a reusable component for consistency.

Next, I worked on implementing an auto-refresh mechanism that updates the page every five seconds. Using useEffect, the function runs at a set interval (which I set to 10 seconds) but only when the page is visible. It detects when the tab is active, triggering the function immediately and then setting up a timer to refresh the data. If the tab is hidden, the timer stops to conserve resources. 

Initially, I applied this feature to all pages that retrieved lists of data. However, Mr. Peter later advised that it should only be implemented on specific lists, prompting me to refactor the logic into a reusable component. I placed this component under the hooks folder and tested it on the selected lists. The component automatically runs when the tab is active, executing a callback function passed from the parent page. The callback was defined as void, simply acting as a trigger.

By the end of the week, the component successfully refreshed the page as intended. However, there was one issue, filters and pagination reset to their initial state upon refresh. This occurred because the component’s useEffect reloaded the content, causing state loss. Resolving this behavior will be the next step in refining the implementation.

Monday, March 17 2025 – Last week, I focused on completing the final features required for this project, at least for now. However, before diving into feature development, I first addressed several UI bugs based on the latest findings. Once those were fixed, I quickly moved on to implementing the new functionality.

The first step was developing the display list. Similar to a previous feature I worked on, this one included two modes: Unprocessed Mode, which filters the list accordingly, and All Mode, which displays the full list along with its relevant features.

Once the table was set up, I proceeded to configure the filters for the All Mode. This whole feature was divided into three main sections, with the second section being relatively straightforward, it simply involved displaying a list of data within a table component. Since no user interaction or buttons were required here, it was a simple implementation.

The final section was the core functionality of the feature. Users needed to search for an item, and if the correct item code was entered, the corresponding data would be displayed, and the next set of actions would become available. If the code was incorrect, the backend would return an error message. Additionally, users were required to input some confirmation details before they could proceed with the Stow button. An Undo button was also included for this feature.

During testing, I initially struggled to execute the stow function. After troubleshooting, I discovered that the issue was caused by the store code not being set to the one the user was currently in. Once I corrected this, the feature worked as expected.

By the end of the week, only one unresolved issue remained which is items from a specific store were not processed correctly, while others worked fine. Investigating this will be my priority for next week.

Monday, March 10 2025 – Last week, I started working on another feature, built upon the existing system. This feature had a similar layout to the one I worked on previously, so I aimed to complete it as quickly as possible. My initial tasks included setting up the display table and implementing search filters on the main page.

Next, I focused on the detail page, working on the layout and command buttons. However, when implementing the create command and sending API requests, I encountered an unclear error that I suspected originated from the backend. To troubleshoot, I verified the validity of the command data before escalating the issue to Mr. Peter. Once discussed the bug in detail, and alongside this, I reported other bugs I had discovered and documented additional UI issues that needed fixing.

By the next day, the bug was resolved, allowing me to proceed with configuring the modes correctly. As the week comes to an end, there are minor adjustments needed for the detail page, particularly in edit mode, which I plan to complete next week.

Monday, March 3 2025 – Continuing from last week, I focused on the detail page, which includes both a read-only mode and a create mode, as there is no edit functionality for this feature. My priority was to complete the create mode first before working on the read-only mode.

The second component I worked on displayed the line items of an order selected from the first table, which lists all available orders. This component allows users to pick line items to be issued. The selected data is then passed to a third component, which consolidates multiple line items from different orders.

Since the feature involves transferring data between components and handling API requests, I had to manage multiple DTOs. Given that both view and create modes were involved, I created a new object to act as a bridge between the DTOs and command requests.

I first ensured that the create command worked successfully. Since there were only two commands for the detail page which is create and cancel, the mode-switching logic was relatively simple. After confirming that the create function worked correctly, I tested the cancel function as well.

By the end of the week, I had completed the feature. However, further testing is needed to identify and fix any remaining bugs.

Monday, February 25 2025 – Last week, I began working on a new feature. Initially, I assumed that the detail view page would closely follow a previous feature I had developed. However, I soon realized that the detail view page required a different approach. The goal of this feature was to align with the existing system’s design.

To simplify the process, I first created a button that displayed a list of orders, allowing users to select one. However, Mr. Peter pointed out that this feature needed to support line items from multiple orders, meaning my initial design was too restrictive. I quickly adjusted my approach and started designing the detail page accordingly.

Similar to my previous feature, I decided to break the page into components. The first component I worked on was the list display. I created a table to list orders and another table to show the line items of a selected order.

As this was a short work week for me, I couldn’t complete all the components. There’s still more to build, and I will continue making progress in the coming week.

Monday, February 17 2025 – Continuing from last week’s progress, I had 2 sections remaining out of 5 to complete. The 4th and 5th sections focused on item details, where the user clicks on an item from a list, and the remaining related details are displayed in the other two sections.

I began with the 4th section by drafting the UI layout, including the text boxes and buttons. Since there was a lot of data to be shown, I spent time optimizing the available space and sorting the elements as efficiently as possible. As this was a component, one crucial piece of data was passed from the parent component. Using that data, I requested details from the API and passed them to the respective text boxes. There were several buttons in this section, and once I confirmed the data was passed correctly, I implemented the functionality for each button. One additional button didn’t require an API call; instead, it calculated a value based on the current information and displayed it, saving the user from doing the math themselves.

Moving to the last section, it was a table displaying the data history, so no additional functionality was needed. My focus was purely on designing the table to fit the available space as efficiently as possible. I created mock data to test the UI and identify any potential bugs.

Next, I revisited the previous feature, where additional data needed to be displayed. While making these changes, I improved the UI by adding a “view” and “edit” mode, helping users distinguish between the two and preventing them from making unsaved changes.

By the end of the week, both features were completed, though I still need to perform testing and clean up the code before pushing the changes.

Monday, February 10 2025 –Last week, I moved on to a new feature that functions similarly to an existing system. To maintain consistency, I designed its UI to follow the same structure. This page consists of five distinct sections.

The first section displays a list, where selecting a specific item reveals another list of line items associated with it. Users can then click on a line item to execute the main function of the page.

Given the complexity of having five sections, I decided to separate them into individual components and work on them one by one. The first section handles the main list, the second displays detailed data for a selected item, and the third presents the line items related to that selection. The fourth and fifth sections show additional details related to the selected line item.

While working on this, I also made minor improvements to a previously developed feature. A button was added to set a status that triggers the new feature. On the detail page, I introduced logic to ensure that certain buttons are only clickable in view mode and hidden in edit mode to prevent accidental actions after making changes.

By the end of the week, I had completed three sections, with two remaining to be finished this week.

Monday, January 27 2025 – Continuing from the previous week, I worked on the same features and focused on completing the filter section. Initially, the filters triggered an automatic refresh whenever the user clicked or typed anything. However, this behavior was modified so that filtering and searching only occur when the user explicitly clicks the search button.

Later, Mr. Peter pointed out that having separate pages for creating and editing items meant any changes made to the create page would need to be duplicated in the edit page, which is not an efficient approach. To streamline the process, I merged both pages by introducing a useState hook to determine the mode. If no data for a specific ID is passed, the page operates in create mode, showing relevant sections only for creation. Otherwise, it switches to edit mode.

By the end of the week, I had made significant progress on this feature and was ready to move on to the next one, though additional checks were needed to ensure error-free functionality.

Monday, January 21 2025 – Last week, I worked on continuing a feature that was partially completed in a project nearing its deadline. Initially, I spent some time understanding the code handed over to me. Unlike my previous project, which involved straightforward functions, this one required me to dive deep into the feature’s implementation. I needed to fully comprehend and familiarize myself with the code before making meaningful progress.

The partially completed code presented challenges, it often gave the impression of functionality when, in reality, it was incomplete. Only after thoroughly dissecting and understanding the logic was I able to proceed with developing the intended feature. With clarity on the existing code, I began by building the “Create Form” page.

This form differed from a previous “Create” page I had worked on. Previously, clicking the “Create” button redirects users to a new page. However, the previous developer for this project had designed it to open as a pop-up, avoiding a full page reload. While implementing this feature, I learned to develop a pop-up page and a dropdown menu by referring to an existing dropdown in the project. I also created a line item table component, with its UI modeled after the existing system.

Throughout the week, I gained valuable insights by working on this feature, adopting new perspectives on development and system design. By the end of the week, I successfully completed the “Create” and “Edit” pages. However, the filters for the list page still require adjustments, which I plan to tackle next week.