Author: nurlailiyuzi

Monday, January 13 2025 – Last week, my primary focus was on resolving bugs in previously developed features, particularly within the report section of our project. Initially, I conducted several rounds of testing directly through the user interface but couldn’t replicate the specific bugs that had been reported. Later, Mr. Peter pinpointed the exact scenario where the bug could be reproduced. With this insight, I quickly identified the issue in the logic calculation and implemented a minor fix in the code.

While addressing this, I took the opportunity to perform thorough testing to ensure the fixes were robust and bug-free. Additionally, I made minor improvements to the UI for better functionality. Similarly, in another part of the codebase, I resolved a similar pattern of errors using a comparable approach.

Towards the end of the week, Mr. Peter assigned me a new task: continuing work on a project that was nearing completion for a specific feature. This project had been primarily handled by an intern who was in the final week of his internship. Recognizing the importance of a smooth transition, I quickly familiarized myself with the project structure and codebase. I took full advantage of the remaining time with the intern, asking as many questions as possible to gain insights and ensure I could handle the project tasks independently moving forward.

Monday, January 6 2025 – Last week, I focused on developing the UI for the sign-in functionality. During this process, I discovered an intriguing security feature: the token received from the API is frequently used to retrieve data that requires authorization. This piqued my interest, as I had always wondered how authorization is managed on the front end.

The token is retrieved and then stored in a cookie. A cookie is a small piece of data stored on the user’s device by their web browser. It allows the website to remember information about the user, such as authentication details, across sessions or requests.

In addition to the sign-in page, I worked on creating related UI elements, such as the edit page. One aspect I found particularly interesting was the process of calling an API to retrieve an entity. To ensure that the user making the request has the necessary privileges, the token must be sent for validation. Unlike passing an ID directly in the URL, which could expose sensitive data, the token is sent securely in the request headers.

This was my first time encountering token-based authorization in this way, and it was a fascinating learning experience.

Next, I shifted to working on another entity. I started by designing the UI, incorporating a dropdown button that supports nested input fields. These fields are dynamically populated based on data retrieved from the API. Once the UI was complete, I moved to the backend to create the API query list that the UI would use.

Monday, December 30, 2024 – Last week, I continued developing the CRUD API for an entity designed to manage metadata on the backend. This entity follows a schema similar to others and is accessible to admins. Once the API development was complete, I ran tests, all of which passed successfully.

With the backend portion done, I transitioned to the UI development. Later, Mr. Peter informed me that the API for another entity was ready for use, which allowed me to begin integrating it into the UI.

I started by implementing the create API into the existing UI. After confirming that the entity could be created without issues, I shifted my focus to the sign-in functionality. Initially, I took a straightforward approach, simply executing the sign-in API command. However, I realized that my implementation might not be entirely correct, as it lacked a mechanism to track whether the entity was logged in.

To refine my approach, I referred to a developed project for guidance. In the reference project, the implementation involved storing the entity’s data and token within the application. This allowed other parts of the application to access the login status when required.

Towards the end of the week, I adopted the same approach in my project. However, the code is still unable to retrieve the login status. I concluded that I might not have stored the data and token correctly, which will require further debugging and adjustments in the coming week.

Last week, I focused on developing the UI for the sign-in functionality. During this process, I discovered an intriguing security feature: the token received from the API is frequently used to retrieve data that requires authorization. This piqued my interest, as I had always wondered how authorization is managed on the front end.

The token is retrieved and then stored in a cookie. A cookie is a small piece of data stored on the user’s device by their web browser. It allows the website to remember information about the user, such as authentication details, across sessions or requests.

In addition to the sign-in page, I worked on creating related UI elements, such as the edit page. One aspect I found particularly interesting was the process of calling an API to retrieve an entity. To ensure that the user making the request has the necessary privileges, the token must be sent for validation. Unlike passing an ID directly in the URL, which could expose sensitive data, the token is sent securely in the request headers.

This was my first time encountering token-based authorization in this way, and it was a fascinating learning experience.

Next, I shifted to working on another entity. I started by designing the UI, incorporating a dropdown button that supports nested input fields. These fields are dynamically populated based on data retrieved from the API. Once the UI was complete, I moved to the backend to create the API query list that the UI would use.

Monday, December 23, 2024 – Last week, I focused on testing the core functionality of the entity, which is to dynamically call APIs and replace the previously hard-coded UI pages. To do this, I integrated the API into the existing hard-coded UI. The design schema was created with flexibility in mind, capable of storing data for multiple pages using a general field name that can be applied across different types of content.

The flexibility of this schema is a crucial aspect of its design. It enables the system to store dynamic content, which can be rendered on various pages without the need to manually create separate DTOs for each page in the UI. Each content section within a page is represented by its own FieldName and FieldValue, where the FieldName can correspond to different parts of the page, such as headers or body text. Additionally, this structure supports nested blocks, allowing content hierarchies where sections can contain other sections, making it adaptable to a wide variety of content needs.

Instead of creating static pages for each type of content, this approach relies on the API to fetch the data for each page, reducing redundancy and making content management easier for the admin. Mr. Peter also suggested adding a preview section to the UI to help users understand what to expect. This introduced a challenge, since the page was designed to be used for multiple types of pages, I had to figure out how to implement a preview specific to each page. After some trial and error, I found a solution, though I’m not sure if it’s the most optimal approach.

Currently, since there’s only one confirmed page for the UI, I inserted a conditional check to determine if the page being managed was the specific one. If it was, the preview would be shown, otherwise, a “nothing to preview” message would be displayed. To facilitate the preview, I divided the UI into a separate component that can be called with the necessary values passed into it.

Additionally, I began working on creating another entity for managing metadata on the backend. This entity follows a similar schema design and will be accessible to admins. Towards the end of the week, I still have few CRUD API functionalities to be completed and will continue working on them next week.

Monday, December 16, 2024 – Last week, my focus was on developing an entity to store and manage information about the website and company. Initially, I designed a simple UI to display this information although everything was hard coded directly into the application. Later, Mr. Peter tasked me with creating an entity/schema capable of storing data for multiple pages, eliminating the need to define a separate entity for each page.

Following Mr Peter guidance, I drafted the potential structure (including key fields and their types) for the entity and discussed it with Mr. Peter. Once the design was finalized, I quickly started creating the context project. Since this entity was built for MongoDB, I discovered that setting up its schema model did not require the same configuration initialization as SQL entities, which I found interesting.

Next, I developed APIs to support the entity, including endpoints for creating, retrieving by ID and URL, and updating. Each API was accompanied by unit tests to ensure proper functionality. Although I encountered a few issues due to oversights, I managed to resolve them, and all tests eventually passed. The logic for retrieving data was notably simpler, likely because only one filter was required at this stage.

Once the backend APIs were functional, I moved to the front end to integrate and test them. Previously, the UI displayed hard coded information, but now I needed to enable admin users to create and edit pages dynamically. I started by creating a page to list all pages, including a “Create” button to navigate to the creation form. After completing the list page, I developed the creation page to test both the list retrieval and creation APIs in action.

By the end of the week, I successfully integrated both the APIs and front-end functionality. Next week, I plan to test the entity’s primary purpose, which is to dynamically call the created APIs to replace the previously hard coded UI pages. Additionally, I’ll also focus on updating the admin page, which requires some additional modifications.

Monday, December 9, 2024 – Over the past week, I transitioned from using an online dummy JSON API to integrating a custom API into the website under development. Initially, the dummy API was instrumental in building the website’s basic layout. Once that phase was complete and a custom API was developed, I began implementing API calls into the project. However, before proceeding with the integration, I needed to synchronize data into the MongoDB database. After completing the sync, I referred to the guide shared by Mr. Peter for further implementation.

Previously, while using the dummy JSON API, I utilized a fetch function that allowed me to retrieve data without relying on useEffect, enabling the page to remain server-rendered. Unfortunately, this approach did not work with the custom API integration. After multiple attempts to implement server-side rendering for the custom API, the approach still failed. Consequently, I decided to switch to using useEffect for client-side rendering as a temporary solution, with plans to revisit and resolve the issue in the future.

Working with the API in Next.js required me some adjustment, particularly in understanding the exceptions being thrown and the proper way to handle them. The custom API created by Mr. Peter also includes admin functionalities such as updating records. By the end of the week, I was able to replace all the previous dummy API calls such as retrieving lists, fetching data by code, and updating entries with our own API.

Monday, December 2, 2024 – Continuing the development process, I implemented the core functionality for displaying the data groups in a newly created component. The primary goal was to create an interactive and user-friendly interface where users could navigate the brands grouped by their initial characters.

To achieve this, I introduced a filtering mechanism using buttons for each group, such as “A-Z,” “0-9,” and special characters. The state management was handled using the useState hook to track the currently selected group. This allowed me to dynamically update the displayed data based on user interaction.

One of the significant challenges was ensuring a seamless experience while maintaining clean and reusable code. Each button was styled conditionally based on its state, whether it’s active, disabled, or default to provide visual feedback to the user so that the user won’t be able to click the group with the empty list. The “All” button was also included for users to reset the filter and view all available groups.

To display the grouped data, I designed a layout where each group had a header styled distinctly to highlight the group name. The list of brands under each group was displayed as cards, each containing an image and a title. I used Next.js’s Image component for optimized image loading and included links to next pages for further exploration.

Next, I focused on cleaning up the entire codebase before pushing the changes. Previously, the API URLs were hard coded directly into each page, which is a poor practice as it risks exposing sensitive information. To address this, I centralized the API URL by placing it in an environment file, enhancing security and maintainability. Additionally, I thoroughly reviewed the codebase to ensure no unnecessary or redundant code remained.

Monday, November 25, 2024 – Last week, I focused on refining the user interface of the website I am currently building. A key milestone was improving the breadcrumbs component, which I initially created by referencing a popular tech blog. While the component functioned well, it did not fully accommodate the dynamic routing I had implemented. Additionally, the homepage unnecessarily displayed the “Home” breadcrumb, which was not ideal.

To resolve this, I added a condition within the component to filter out the “Home” breadcrumb when the route was read in the component originated from the homepage. This adjustment worked; however, another challenge arose, displaying the dynamic slug route appropriately within the breadcrumb. Since I used Next.js optional dynamic routing for SEO purposes, the breadcrumb also displayed irrelevant object names instead of just the intended page titles. To address this, I added a filter to clean up the route data, ensuring it displayed the desired output. After some iteration, this solution worked, but I am still reflecting on whether my implementation aligns with clean code principles.

In addition to the breadcrumb enhancements, I revisited the thumbnail gallery component I had previously created. While the design required only minor tweaks, I realized that turning this component function to a client-rendered only on the edge component was essential. The gallery’s functionality relies on a callback to update the main image display when a thumbnail is hovered over. This required using useState, which automatically converted the page to a client-rendered component.

To enable server-side rendering, I refactored the gallery by exporting the main image and thumbnail into their own components. This allowed state changes to be handled outside the page itself. After some trial and error, I successfully implemented this approach.

Throughout the week, I also worked on basic structural components like the navigation bar, footer, and header. While these designs are currently simple, I prioritized practicality to ensure functionality.

Towards the end of the week, I discovered an oversight, one of the pages was still fetching data from a JSON sample file instead of a dummy API. This conflicted with my plan to render the page on the server side. After switching to the API, the page became client-rendered again. I’ve marked this as a task to revisit later, as my focus is currently on completing higher-priority items.

While there’s still much to do, these iterative improvements have brought me closer to achieving goals for the project.

Monday, November 18, 2024 – Last week, I focused on enhancing the user interface of a Next.js website, specifically designing a page where images serve as the main attraction. Before diving into image implementation, I first tackled the challenge of structuring the website path for this page. The goal was to create a dynamic route that incorporated multiple parameters in the URL, ensuring it was both descriptive and SEO-friendly.

To achieve this, I utilized Next.js dynamic routing by wrapping file or folder names in square brackets [segmentName]. However, since the segment combined multiple data points, I initially struggled to retrieve the data correctly. Eventually, I discovered that using Optional Catch-All Segments allowed me to retrieve multiple parameters seamlessly, resolving the issue.

With the routing set up, I shifted my focus to building a thumbnail gallery for the page. As I had limited experience with such implementations, I researched how to achieve this using Tailwind CSS. Initially, I was uncertain whether Tailwind alone could handle the task or if I needed a third-party package for pre-built components. To my surprise, Tailwind proved to be a powerful tool. Its utility-first classes enabled me to design the gallery effectively, including adding hover effects and transitions without needing JavaScript or React hooks for simple interactions. This approach helped keep the page lightweight by minimizing unnecessary client-side rendering. 

During the trial-and-error process of designing the gallery, I referred to a sample website provided by Mr. Peter and explored popular design references online to create a visually appealing layout.

For this page, I also needed icons. At first, I considered using an external icon library. However, I hesitated, as importing a library, especially one that isn’t widely used or actively maintained, might not be ideal for long-term project stability, especially since I only needed a few icons. I then found an alternative: using SVGs as components, which turned out to be a flexible and lightweight solution. By leveraging an AI tool, I generated customizable SVGs that allowed me to adjust their colors and sizes without pixelation issues. These SVGs fit seamlessly into the project.

Throughout the week, I focused on beautifying the thumbnail gallery to enhance the user experience. I implemented hover effects on the images, making interactions more engaging and visually appealing.

Last week, I continued working on CRUD operations for an API, specifically focusing on retrieving lists from a newly created entity. The task was progressing smoothly until I reached the SQL query part. As someone new to writing SQL queries, I felt uncertain about the best approach to querying across multiple databases. In my previous experience with EF Core, I could simply use the Include() function to fetch data from related tables. However, doing the same in raw SQL required a different approach.

To handle data from multiple tables, I quickly realized that JOIN statements would be essential, so I dove into learning SQL joins. Although it seemed complex initially, I found that retrieving columns from multiple tables was not as difficult as I anticipated. Using SQL joins allowed me to efficiently pull data across related tables, achieving similar functionality to what Include() provides in EF Core but with SQL-specific syntax and nuances.

After grasping the join concepts, I moved on to testing and refining the query based on errors that emerged during execution, which helped me improve the overall structure. Once the read operation was stable, I developed the create operation for the entity and wrote tests to validate it. Although this entity will have additional table relationships that shall be integrated later, the essential read and create API functionality was successfully implemented. For now, I skipped implementing a delete operation, as it doesn’t align with the entity’s purpose; however, further discussion shall be made.

Toward the end of the week, I returned to my Next.js work, focusing on SEO-friendly dynamic routing for the project. I’m exploring the updated dynamic route handling introduced in Next.js 13, which differs from previous versions. Though I haven’t achieved the desired setup yet, I plan to continue refining this next week.