Welcome to our fourth lesson in building an image generation web application with Spring Boot!

In our previous lesson, we implemented the core JavaScript functionality for our application, including tab navigation and the image generation process. We also introduced basic loading states and error handling for the image generation feature.

In this lesson, we will build upon that foundation to create a more comprehensive user experience by focusing on the history tab functionality. We will implement loading states and error handling specifically for retrieving and displaying previously generated images.

When working with web applications that make API calls, it is crucial to provide users with clear feedback about what is happening behind the scenes.

Without proper loading indicators, users might wonder if their action was registered or if the application is frozen. Similarly, without proper error handling, users might be left confused when something goes wrong.

We have already seen how loading states and error handling work in our generateImage() function. Now, we will apply similar principles to our history feature, ensuring a consistent and user-friendly experience throughout the application.

Our application has two main tabs: one for generating images and another for viewing previously generated images. In this lesson, we will focus on implementing the functionality for the history tab, which allows users to retrieve and view their image generation history.

Let's get started by implementing the fetchHistory() function that will handle the retrieval of image history from our backend API.

Now that we understand the importance of providing feedback during API operations, let's implement the fetchHistory() function that will retrieve the user's image generation history from our backend API.

This function will be called when the user clicks the "Load Previous Images" button in the history tab. It will send a request to our backend API, retrieve the list of previously generated images, and display them in the history container.

Here is the implementation of the fetchHistory() function:

Let's break down this function step by step:

First, we get references to the DOM elements we will need to update during the history retrieval process:

These elements include the history-loading-message that will be displayed while the history is being fetched, the history-button that the user clicks to load the history, and the history-container where the images will be displayed.

We update the UI to indicate that history retrieval is in progress:

This shows the loading message, hides the "Load Previous Images" button, and clears any previously displayed images from the container.

Then, we send a GET request to our backend API to retrieve the image history:

Unlike the image generation function, which sends a POST request with user input, this function sends a simple GET request to the /api/get_images endpoint. We expect the response to be a JSON object containing an array of image data.

Once we receive and parse the response, we update the UI based on the data received:

To ensure a smooth user experience, we handle errors as follows:

This resets the UI and shows a helpful message.

First, we reset the UI by hiding the loading message and showing the button again. Then, we check if the response contains any images. If not, we display a message indicating that no images were found by checking data.images.length.

If there are images, we iterate through each one using forEach, create an img element for it, set its src to a data URL containing the base64-encoded image data from image.image_base64, and append it to the history-container. This will display all previously generated images in the history tab.

With this function in place, users can now click the "Load Previous Images" button in the history tab to view their image generation history. The fetchHistory() function will retrieve the images from the backend API and display them in the history-container.

In the previous section, we implemented the fetchHistory() function to retrieve and display the user's image generation history. Now, let's take a closer look at how we are managing loading states during this process.

Loading states are visual indicators that inform users that an operation is in progress. They are especially important for operations that might take some time to complete, such as API calls. Without loading states, users might think that the application is frozen or that their action was not registered.

In our fetchHistory() function, we manage loading states by toggling the visibility of certain UI elements:

Before sending the API request, we show the loading message by setting display to 'block', hide the "Load Previous Images" button by setting display to 'none', and clear any previously displayed images from the container using innerHTML. This provides immediate feedback to the user that their action was registered and that the operation is in progress.

After receiving the API response, we hide the loading message and show the button again, indicating that the operation has completed. We then update the history-container based on the data we received.

In our HTML, we have already set up the loading message element with an initial display: none style, which means it is hidden by default:

This element is only shown when we explicitly set its display style to 'block' in our JavaScript code.

By managing loading states in this way, we provide a better user experience by giving clear feedback about what is happening behind the scenes. Users can see that their action was registered and that the application is working on retrieving their image history.

In addition to managing loading states, it is important to handle the various types of responses and potential errors that might occur during the history retrieval process. Let's take a closer look at how we are handling these scenarios in our fetchHistory() function.

First, consider the case where the user has no previously generated images. In this scenario, the API response will contain an empty array of images. We handle this case by checking the length of the data.images array and displaying a message if it is empty:

This provides clear feedback to the user that there are no images to display, rather than leaving the container empty, which might be confusing.

Let's consider the case where an error occurs during the fetch() operation. This could happen for various reasons, such as network issues, server errors, or invalid responses. We handle these errors in the .catch() block:

When an error occurs, we reset the UI by hiding the loading message and showing the button again. We then display an alert() with a user-friendly error message, encouraging the user to try again. We also log the error to the console using console.error() for debugging purposes.

It is worth noting that we are using a simple alert() for error messages in this example. In a production application, you might want to use a more sophisticated approach, such as displaying the error message in a designated area of the page or using a modal dialog.

By handling errors in this way, we ensure that users always receive appropriate feedback, even when things do not go as expected. This contributes to a more robust and user-friendly application.

Let's consider the successful case, where the API response contains one or more images:

For each image in the response, we create an img element, set its src to a data URL containing the base64-encoded image data, and append it to the history-container. This displays all previously generated images in the history tab.

By handling all these different scenarios, we create a comprehensive user experience that provides appropriate feedback in all situations, from successful operations to empty results and errors.

To test our implementation, you can follow these steps:

1. Ensure that your Spring Boot application is running and that the /api/get_images endpoint is properly implemented to return a list of images previously generated through the official Gemini API using gemini-3.1-flash-image.
2. Open your application in a web browser and navigate to the history tab by clicking on the "View History" tab button.
3. Click the "Load Previous Images" button to trigger the fetchHistory() function.
4. Observe the loading message that appears while the history is being retrieved.
5. Once the history is retrieved, observe the images that are displayed in the history-container.
6. If there are no images, observe the "No images found." message that is displayed.
7. To test error handling, you can temporarily modify your code to simulate an error, such as by changing the API endpoint URL to one that does not exist.

Now that we have implemented the fetchHistory() function with proper loading states and error handling, let's review what we have accomplished.

In this lesson, we have built upon the foundation laid in the previous lesson to create a more comprehensive user experience for our image generation web application. We have implemented the fetchHistory() function, which retrieves and displays the user's image generation history. We have also added proper loading states and error handling to ensure that users receive appropriate feedback during the history retrieval process.

Remember that proper loading states and error handling are crucial for creating a good user experience in web applications. They provide feedback to users about what is happening behind the scenes and help them understand and recover from errors.

In the practice exercises following this lesson, you will have the opportunity to experiment with the code we have written and further enhance the user experience of our application. You might try adding more sophisticated loading indicators, improving error messages, or implementing additional features such as pagination for the history view.

By mastering the concepts covered in this lesson, you will be well-equipped to create web applications that provide a smooth and user-friendly experience, even when dealing with asynchronous operations and potential errors.