In this guide, I’ll introduce you to Postman, a popular API development and testing tool.

If you are a beginner mainly focused on frontend development, you may not have had much experience fetching data from an API. And in that case you probably haven't encountered many situations where you need to make multiple requests to an API for testing purposes during your development process.

But understanding how to test APIs and connect with them via Postman or similar tools will become important at some point in your career. If you decide to venture into backend development, understanding these concepts is essential.

After covering some basic information about Postman and the Spotify API documentation, we’ll dive into more key Postman features. Then, we’ll select one Spotify endpoint and walk through the process of making requests to it.

🔐 Here's What We'll Cover

• You'll gain fundamental knowledge of working with Postman.

• You'll strengthen your ability to work with APIs and their documentation.

• You'll explore the basics of the public Spotify API.

📝 Prerequisites

• You should have a basic understanding of APIs.

• You don't need any prior knowledge of Postman.

Table of Contents

1. Exploring the Spotify API with Postman

2. The Postman Experience

3. How to Make Your First Request to the Spotify API

4. Spotify API Authorization

5. Spotify API Authorization Scopes

6. Summary

Exploring the Spotify API with Postman

To get a brief overview of what Postman is, let's refer to the following explanation from ChatGPT:

"Postman is a popular API (Application Programming Interface) development and testing tool that simplifies working with APIs by providing an easy-to-use interface for sending HTTP requests and receiving responses. It's widely used by developers, QA engineers, and teams who work with APIs to ensure they function correctly and efficiently."

While we will focus on making HTTP requests, it's important to note that Postman is also versatile and can be used to work with GraphQL, gRPC, WebSocket, Socket.IO, and MQTT.

With Postman in hand, we need an API endpoint to test. For this, we’ll use the public Spotify API, which offers a variety of endpoints for different use cases. This can even be an exciting opportunity for your next project if you're a beginner looking for a fun project to explore.

The Spotify Web API is professionally designed, offering all the necessary information for developers. With their "Overview" and "Getting Started" sections, it's straightforward to follow along, even for beginners.

While learning the basics of Postman, we will explore key parts of the Spotify API documentation necessary for successful API testing. For instance, we will demonstrate how to make an HTTP request to the endpoint for retrieving data from a playlist.

But first, let’s cover some Postman fundamentals.

The Postman Experience

You can use Postman in a number of different ways. In my case, I'm using the desktop version of Postman.

But you can also use Postman directly in your browser, or even via the Postman CLI (Command Line Interface). There's also an official Postman extension for VS Code. You can find these versions through the link I just shared.

If you're completely new to Postman, you may want to start with the web version or the downloadable desktop version, especially if you plan to use Postman regularly in the future.

After starting the desktop version of Postman, the first thing you’ll see is this:

This might look slightly different from what you see initially. I already have an account. You may need to create one first for free. You also may need to create a workspace first. In my case, I’m already inside the "My Workspace" workspace.

In the upper left corner, you'll find several tabs, including "Collections", "Environments", "History", and an icon to configure this sidebar.

For now, we’ll stay on the "Collections" tab and click on "Create Collection":

Once you click on that, your focus will shift to the name of the collection in the top center. By typing, you can rename your collection from "New Collection" to something more appropriate for your specific use case.

For this case, I named the collection "Spotify API":

Now, we have a collection, but what exactly is that? A collection is essentially a space to organize multiple request structures. This will become clearer once we add our first HTTP request. You can do this by clicking on the blue text that says "Add a request":

When you do that, your focus will again be on the name of the element. If you type something now, you can rename the request from "New Request" to something more appropriate for the situation. In this case, since I’m not sure which request I want to create yet, I'll simply call it "test" for now.

If you'd like to create another request at this point, you can click on the three dots to the right of the collection's name (the 6th option):

There are multiple options you can choose from, with "Add request" being one of them.

At this point, we've created a collection within our workspace, and inside that collection, we've added an HTTP request. You can have multiple collections, each containing multiple requests. This helps organize your requests, especially when you reach a point where having one large list of pre-configured requests becomes cumbersome to manage.

On the newly created HTTP request, we can see some details:

The first thing you might notice is the HTTP request method, which is set to "GET" by default. If you click on "GET" with the downward arrow, you can choose from various methods or even type in your own if needed.

To the right of that, there’s a text field where you'll enter your API’s URL along with its endpoint (we'll try this shortly).

Below, there are several important tabs. Right now, we're on the "Params" tab. Here, you can add key-value pairs that will directly modify the request you're making. These are called Query Params, which you may have encountered before. For example, if your URL is https://google.com, adding a key-value pair as a Query Param might look like this:

As for Query Params, whether you need them depends on the request you're making. A common use case would be pagination on a website with a table. For example, you might use a query param like "page=4" to specify which page of results you want.

Next is the "Authorization" tab, which handles authentication and authorization for your request. We’ll cover this in more detail later, so we’ll skip it for now.

Then, we have the "Headers" tab, which is crucial because it contains all the information included in your request’s header, such as any authorization data if that’s set up.

Finally, the "Body" tab, located to the right, is also quite important. For instance, if you’re making a POST request to add an item to a database, you’d likely need to send information such as the item’s name or category. This kind of data is often included in the request body in JSON format.

To add JSON-formatted data, you can click on "raw" within the "Body" tab, and then select the format you want (with "JSON" being the default option):

As with Query Params, the format and data required depend heavily on the API and endpoint you're using. Just keep in mind that you can configure all the necessary options within these tabs.

The remaining two tabs are "Scripts" and "Settings." In the "Scripts" tab, you can add custom code, but this is more advanced and not necessary for our current situation. The "Settings" tab allows for adjustments, though in most cases, you won’t need to modify anything here.

How to Make Your First Request to the Spotify API

Now, we’ll make our first actual request using Postman. For this, we can dive into the Spotify API developer documentation, where all endpoints are listed. For this first test, we’ll fetch data about a playlist.

In that description, you’ll find a wealth of useful information, including the endpoint and the required data for a successful response. You also have the option to make the request directly from the page after logging in with your Spotify account:

Such extensive API documentation is incredibly helpful and makes it easy to work with, especially for beginners. Keep in mind, though, that not all API documentation is this thorough.

In this case, we can see the endpoint is https://api.spotify.com/v1/playlists/{playlist_id}, with playlist_id being the only required parameter in the curly brackets. You’ll also see optional parameters like market, fields, and additional_types, which can help refine the response. But again, these are optional, and you only need playlist_id for the basic request.

If you want to include optional information, like market, you’d use the Query Params mentioned earlier. For example, adding ES as the market alongside the playlist_id would change the URL to: https://api.spotify.com/v1/playlists/3cEYpjA9oz9GiPac4AsH4n?market=ES.

To make the basic request in Postman (without any optional parameters), we’ll return to our "test" request and enter the URL with the corresponding endpoint:

This approach will work, but I recommend another method.

Since we have our Spotify API collection and may want to add multiple requests to that collection, it's a good practice to use variables for sections of the URL or information that will remain consistent across multiple requests. In this case, the base URL, https://api.spotify.com/v1/, will stay the same for all Spotify API requests. Instead of manually adding it to every request, we can create a variable for it.

To do this, we’ll switch to the "Environments" tab in the upper left corner. From there, click on the plus icon to create a new environment:

We'll name the environment “Spotify API”.

Next, we'll create variables, such as base_url, and assign the appropriate value to it. You can also choose between the type options: default or secret. Since this isn't sensitive data, it can remain set to default. If you choose secret, you'd need to click on an eye icon to reveal the variable’s value each time, otherwise, it would be masked with ••••, similar to how passwords are displayed.

Here’s what it looks like so far:

Next, we’ll return to the Spotify API collection and look at the upper right corner, where it currently says "No environment". Click there and select the "Spotify API" environment that we just created:

Now, we can use the variables from that environment for all the requests within the "Spotify API" collection. To insert a variable, you’ll use double square brackets, like this:

If you receive a message that the variable couldn't be found, make sure to save the "Spotify API" environment. The dots on the right of the tab names indicate that you can save new information by pressing CTRL + S, for example. This step is necessary for the created variable to be recognized.

With the variable in place, you can now modify just this one variable to change the base_url for all your corresponding requests. While this may not seem immediately useful for the base_url, since it likely won’t change anytime soon, variables can be incredibly helpful in other scenarios. This was an opportunity to introduce you to how they work.

Next, I’ll rename the HTTP request from "test" to something more descriptive, like "Playlist," to indicate what this request is about. Along with the "GET" method, it will be clear that this request is for fetching playlist data.

Now that everything is set, let's send the request by clicking the "Send" button on the right while viewing the HTTP request. You’ll see the response appear in the bottom half of the screen:

What a bummer, the request wasn’t successful!

This happened because we didn’t provide any authorization. That’s why we received a "401 Unauthorized" error with the message "No token provided".

Since this is a protected endpoint, we need an access token, which you would obtain by logging into Spotify. If you tried making a request on the Spotify API documentation website earlier, you probably noticed that it asked you to log in before sending the request. By doing so, it acquired your session's access token, which is exactly what we need in our situation as well.

However, instead of logging in with our username and password, we’ll use a different authorization method.

Spotify API Authorization

To make basic requests to the Spotify API, you'll need an access token, which can be generated using your credentials. This is a common approach with many APIs, where you need to obtain an access token before you can access the endpoints you're targeting.

The Spotify Developer API provides a step-by-step guide on how to get your access token.

Following the outlined steps, the first task is to create an application profile, which you can do in just a few seconds, especially for a test project:

After completing this step, we can proceed by clicking on the "test" project to navigate to the "Settings" of the project. Here, you'll find the "Client ID" and "Client Secret":

Keep in mind that this information is generally considered sensitive, so you should avoid sharing it publicly (in most cases). But since this is just a test project, which will be deleted by the time this guide is published, I am showing it to make it easier for you to follow along with my explanations.

With your Client ID and Client Secret in hand, you now have the information needed to request an access token. These access tokens are used to authorize yourself when interacting with API endpoints.

You can kinda compare this to logging into software, where you need to authenticate yourself before accessing certain information. In such cases, it’s likely that an access token is generated for the duration of your session to authorize your requests to the software’s backend API.

Also, remember that access tokens change with each login session, meaning you receive a different token every time. Just keep in mind that with our current selected method, we don’t have access to specific user information. Instead, we only can make basic GET requests without acting on the behalf of a user. Later on we will cover this a little more.

The Spotify API documentation is quite helpful and provides detailed instructions on the exact request you need to make. We’ll now jump into Postman for this step.

Go to your "Spotify API" collection and click on the "Authorization" tab. Here, you need to choose the appropriate "Auth Type". There are several options, and the authorization method can differ depending on the API you’re using.

If you already have an access token, you may opt for the "Bearer Token" auth type, where you simply paste the token directly. This is the type of authorization we’ll use in the end. But instead of manually requesting a token and then inputting it into the "Bearer Token" field, we can automate this process. For this, we’ll select "OAuth 2.0" as the auth type.

How did I know "OAuth 2.0" was the right choice? If you check the Spotify API documentation, you’ll find some corresponding information while going through their step-by-step guide. Also, all endpoints that need authorization are tagged with "OAuth 2.0", including the "Get Playlist" endpoint:

The documentation also mentions that Spotify uses "Client Credentials" for its tutorial. This is the "grant type" and indicates the information you’ll provide for the authorization request. With "Client Credentials," you pass your Client ID and Client Secret (the information from our test application).

For instance, with the "Password Credentials" grant type, you would also pass a "Username" and "Password," which is used when logging in with an actual user account.

There are other authorization methods as well, and the API documentation usually specifies which approach to use. In our case, since we have the Client ID and Client Secret and don’t need specific user access, we know the "Client Credentials" grant type is the appropriate choice.

When passing your Client ID and Client Secret in Postman, you may receive a suggestion to use variables for this information:

Similar to the base_url variable we used earlier, creating variables for the Client ID and Client Secret can be helpful, especially if you plan to use multiple HTTP requests with similar authorizations. This way, you can reference the same variables in all your requests, and if anything changes, you only need to update the variable in one place.

In this case, we’ll do the same by switching to the "Environments" tab and adding variables for both client_id and client_secret.

Next, you’ll insert those variables into the authorization process we started earlier:

Now, we just need to add the token authorization URL, which can be found on the same page as before: https://accounts.spotify.com/api/token. Enter this into the "Access Token URL" field. Then, give the setup a fitting name of your choice and scroll down to click the "Get New Access Token" button:

It was successful! Now, click on "Proceed" to view more details about the generated access token:

With our access token ready, click on "Use Token" in the upper right, and Postman will confirm that the token has been added.

Now, if we switch to the "Playlist" GET request we created earlier, you’ll see the option to set up an authorization method for this specific request. But since we’ve already set up authorization for the entire collection, simply select "Inherit auth from parent" as the "Auth Type" for this request:

Postman will indicate which authorization type is being used and where it’s coming from. In this case, it will say: "The request is using OAuth 2.0 from collection Spotify API."

Next, if we switch to the "Headers" tab and click on "8 hidden," we can see an "Authorization" key. By clicking on the eye symbol to the right, we can reveal this information.

If you compare this with the access token we just generated, you'll notice they are the same (with "Bearer" in front of the actual access token). When you create a new token for the collection, as we did earlier, this information updates automatically.

With everything set up, we are now ready to send the request we tried earlier, this time with a valid access token in the "Authorization" header.

And if we now hit "Send", we will get a response like this:

The response is a JSON object containing a lot of information to explore. You can do this for your own playlist as well, as long as it’s set to public on Spotify.

To give another example, I’ll go to Spotify, use the "Share" option for my playlist, and copy the playlist link, which looks like this: https://open.spotify.com/playlist/1OPgvkPckzXm9SB0CIJf3o?si=cbe9c361f8024abd.

The part we’re interested in is the playlist ID, which is found after the last forward slash and before the question mark—in this case, 1OPgvkPckzXm9SB0CIJf3o. We’ll replace the current playlist ID with this one in Postman:

Now, if we hit "Send," we’ll receive the corresponding JSON response:

This response is also a large JSON object with plenty of data to explore.

And that's it! We've successfully configured a fundamental Postman setup with an HTTP GET request, including authorization, to fetch data from the Spotify API.

Spotify API Authorization Scopes

By now, we’ve successfully used authorization with our Client ID and Client Secret. But if you dive deeper into the Spotify API documentation, you’ll find situations where this method of authorization is insufficient for certain actions.

While fetching playlist data and other GET requests work with Client ID and Client Secret authorization, you may encounter endpoints that use POST, PUT, or DELETE methods.

For example, adding new songs to a playlist requires more than just Client ID and Client Secret authorization. You need to authenticate as the actual user associated with the playlist.

In such cases, the documentation lists "Authorization scopes" that define the required permissions. For instance, "playlist-modify-public" and "playlist-modify-private" scopes are needed for modifying public and private playlists, respectively:

If you review the Spotify API documentation, you’ll see that it outlines four main authorization methods:

• Authorization code

• Authorization code with PKCE extension

• Client credentials

• Implicit grant

The Client credentials method (which we used) does not provide access to user-specific data. To perform actions on behalf of a user, such as modifying their playlists, the "Authorization code" method is required.

In real-world projects, you would typically implement this as part of your app's authentication and authorization process when users log in. For instance, in Next.js projects, NextAuth offers a Spotify login mechanism that simplifies this process.

Alternatively, you could manually handle the necessary requests during the authentication process and add relevant data to the session information.

This topic goes beyond the scope of this guide, as it deals with general authorization and authentication flows for the Spotify API (and other APIs) rather than Postman-specific use cases. But the Spotify API documentation provides valuable resources if you’re interested in exploring more advanced testing with Postman. They also provide a how-to guide on retrieving a user's profile data and displaying it in your frontend application.

Summary

In this guide, we covered the fundamentals of Postman: how to set up your first workspace with a collection, create an HTTP request, use variables to simplify the process for future requests, and add authorization logic to obtain an access token required for making requests. All of this was demonstrated using the Spotify API, which provides extensive documentation on accessing its endpoints.

From here, you might want to explore deeper by learning how to access Spotify API endpoints that require user-specific access information, combined with specific scopes, such as adding new songs to a Spotify playlist.

Getting familiar with these concepts can help you make sure your upcoming React.js applications stand out.

🔐 Here's What We'll Cover:

• Crafting a Blender model, encompassing animations, materials and the export process.
• Building a React.js application integrated with Three.js via React Three Fiber.
• Incorporating your personally created Blender model into the React.js application.

📝 Prerequisites:

• A fundamental grasp of the 3D software Blender is recommended.
• Basic familiarity with React.js is required.
• Prior experience with Three.js is not necessary.

Table of Contents

1. 💭 What are Three.js and Blender?
2. 🔧 How to Set Up React.js with Three.js
3. 🔨 How to Create a Blender Model
4. ✏️ Texture Baking for Procedural Materials
5. ✒️ How to Implement the Blender Model into the React.js Application
6. 📄 Additional information
7. 📋 Wrap-up

💭 What are Three.js and Blender?

Three.js is a JavaScript library that functionas as an API, allowing you to exhibit 3D models within web browsers.

Leveraging Three.js helps you seamlessly integrate interactivity and distinctive functionalities into your website.

Blender is a robust software tailored for crafting and refining 3D models. Its versatility offers boundless opportunities, catering to a wide spectrum of creative visions.

Beyond its display capabilities, Blender provides you with an array of tools encompassing cameras, lighting, and even post-production enhancements.

When used together, these tools facilitate boundless creativity, allowing you to seamlessly translate your artistic creations into your upcoming website project.

🔧 How to Set Up React.js with Three.js

To start the process, install the React.js application:

npx create-react-app my-app

Next, we'll install Three.js and React Three Fiber. React Three Fiber serves as a React renderer for Three.js, harnessing the power of React components to streamline Three.js integration within a React.js environment:

npm install three @react-three/fiber

For an enriched Three.js experience, we'll also integrate React Three Drei, a package that introduces an assortment of helpers for diverse Three.js scenarios, including several camera controls, for example:

npm install @react-three/drei

glTF Tools extension

I also recommend installing the glTF Tools extension. Although not strictly necessary, this extension can help you perform various tasks.

If you're using Visual Studio Code as your Integrated Development Environment (IDE), you can conveniently add the extension through the extensions tab. Again, this extension is optional, but it can significantly simplify certain processes later on. I will use it throughout this tutorial:

gltf Tools extension in Visual Studio Code

Completed setup for Three.js in React.js

The dependencies in the package.json file of our React.js application now appear as follows:

"dependencies": {
    "@react-three/drei": "^9.80.2",
    "@react-three/fiber": "^8.13.6",
    "@testing-library/jest-dom": "^5.17.0",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^13.5.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1",
    "three": "^0.155.0",
    "web-vitals": "^2.1.4"
  },

These dependencies are sufficient for accomplishing a variety of tasks with Three.js in a React.js environment. Of course, you can incorporate any additional libraries you may desire for purposes beyond Three.js integration.

In addition to this, I have also made the code from this tutorial available on GitHub. This will allow you to quickly access the information without having to scroll through the entire article.

🔨 How to Create a Blender Model

To begin, our initial task involves creating a Blender model that will then be integrated into our React.js application. For this stage, let's consider a scene in the Layout tab where we've got three objects: two spheres and one plane. You can add such objects with the Shift + A shortcut in Blender.

Blender scene with two spheres and one plane in the Layout tab

This composition includes just a plane and two spheres, with no additional details. Of course, you can work on more elaborate scene and model designs according to your preferences.

But for the purpose of illustrating the fundamental process of incorporating your custom Blender models into React.js, this basic example will serve us just fine.

How to add animations to the model

Now, our focus shifts to introducing basic animations to all three objects within this Blender scene. These animations can facilitate movement, rotation, or even adjustments in scale for the objects, enabling dynamic transformations.

In order to add animations in Blender for your objects, you can switch to the Animation tab, next to the Shading and Rendering tab.

In the Animation tab, you can add points to a certain frame. For instance, if you want to shift a sphere a bit to the left, begin by adding a starting keyframe (right-click on the object, choose "Insert Keyframe," then pick "Location").

Afterward, move ahead a few frames on the object's animation timeline, adjust the object's position, and repeat the same process. This way, you'll have two keyframes: the initial one and the new position.

Remember, this motion is in one direction. If you want to repeat the animation, it will move to the new location and then return to its initial position with a jump.

To make the movement smoother, you can copy the initial keyframe and insert it at the end. This will make the object move back with a smooth motion after reaching the new location. This is also how I set up the keyframes in our Blender model.

Of course, you can add more keyframes to make more complex animations. This is just a basic introduction to starting with Blender animations. Like many aspects of Blender, there's a lot more to explore and learn.

Adding animations to all three objects in the Animation tab

In this context, it's not necessary to have a thorough understanding of the specifics of these animations we added here. So, you don't really need to know to which exact position the first sphere is being moved through the animation.

The key point is to acknowledge their presence, as they will be integrated into our React.js application at a later stage so we can activate them in the browser.

How to add colors

Moving forward, we'll add some simple colors for the small sphere and the underlying plane, which you can do within the Shading tab, for example.

For basic colors, you can also go to the Material Properties section of the object (right-click on the object, then choose the second-to-last category at the bottom). But I want to focus on a specific situation you might encounter with your models later on. Therefore, I'll exclusively use the Shading tab for setting object colors in this tutorial.

In the Shading tab, you can add nodes at the bottom of the screen. These nodes can modify the color and texture of an object, among other things. You'll also find Vector and Shader nodes that, when combined, can create unique visuals for your objects.

All these adjustments apply to a specific material. So, if you want the same visual for different objects, you can simply apply the same material to them.

The Principled BSDF and Material Output nodes are initially generated when we open the Shading tab to look up on of our object's material for the first time. Both nodes are pretty much the basic case.

The Principled BSDF has a lot of settings you can play around with. In our case we just want to change the Base Color property to a blue color.

Material of one sphere where we just adjust the Base Color within the Principled BSDF node

For the larger sphere, a similar material application is used. But, in contrast to the Principled BSDF node, we'll use the Glossy BSDF node which is such a node from the Shader category. This will help us recognize a possible issue that you might come across when designing a Blender model for your React.js application – which you will see later on.

Using the Glossy BSDF node to add a material to the large sphere

Once we've done this, we're ready to export our Blender model. Note that this version is considerably simplified. You can work on more detailed model designs tailored to your preferences. Still, the overall workflow remains similar.

How to export the model

To export the model, we need to generate a .glb/.gltf file. This is crucial as Three.js expects particular file formats for compatibility, and in this instance, a .glb or .gltf file aligns with the library's requirements.

So, once you've finished creating your model with objects, animations, colors, and more, you can do the following:

1. Click on the File tab located at the top left corner.
2. Choose Export from the options that appear. Now, a variety of export formats will be shown.
3. If you plan to use your model with Three.js in your application, you need to pick the glTF 2.0 (.glb/.gltf) option, like I mentioned earlier.

After selecting this option, a new window will pop up. This window lets you pick the folder where you want to save your file.

On the right side of this window, there are additional choices. You can decide which specific objects you want to export, for instance. In most situations, the default settings should work well. Just remember that you can adjust these settings to your liking if necessary.

Remember to export with the glTF 2.0 (.glb/.gltf) format.

How to visualize the exported model

Next, let's transition to Visual Studio Code and navigate to the folder where we've stored our exported file.

Within this directory, you'll find a .glb file. Referring back to the glTF Tools extension setup from earlier, you can simply right-click on the .glb file in order to find two additional options positioned at the bottom, called glTF: Import from GLB and glTF: Validate a GLB or GLTF file.

In this scenario, we'll opt for the glTF: Import from GLB option. This action will generate a .gltf file in the same folder, in our case blenderFile.gltf.

Generating a .gltf file from the original .glb file we exported in Blender with the glTF Tools extension

We've chosen this approach to bring enhanced accessibility to the .gltf file, enabling direct viewing within Visual Studio Code through the glTF Tools extension. This can be quite helpful to check on your file prior to its actual implementation.

If we access the newly created .gltf file, we can observe a bunch of information based on the Blender model. It's important to note that the specifics could differ in your case, as they're tailored to reflect the attributes of the objects and scenes within your Blender project.

If we look at the upper-right corner, there is a symbol that looks like a cube with a cone next to it. By clicking on this symbol, you can seamlessly preview your Blender scene directly within your IDE. This functionality is exclusively accessible for the .gltf file and not applicable to the .glb file in this case.

The newly created .gltf file with the option to view the model directly in Visual Studio Code (in the upper-right corner, circled in red)

It's worth noting that you don't have to do this through the glTF Tools extension. Alternatively, various websites allow you to upload your file for visualization. But I've personally found this in-IDE approach to be especially convenient. It centralizes the process, enabling you to assess your file's integrity before actually implementing it.

If you find any errors, this practice lets you preemptively find out whether the issue is based on a problematic file export or just an implementation oversight within your React.js application. Consequently, I wholeheartedly recommend evaluating your model file following its export from Blender.

Viewing the Blender model with glTF Tools in Visual Studio Code

By using the glTF Tools extension to view our Blender model in Visual Studio Code, we can see that all three objects are correctly recognized. Both the small sphere and the plane are shown in their intended colors.

But the large sphere doesn't have the expected color assigned and just appears with a default white color instead.

This discrepancy raises the question: what led to this anomaly? It's circumstances like this that demonstrate how useful it is to preview your model before integrating it into your React.js application.

By scrutinizing your model at this stage, you can affirm that the issue originates from the Blender model itself rather than the implementation process, given that we haven't done any implementation yet.

This pre-implementation assessment proves to be handy and enables you to diagnose and address potential complications before proceeding with the implementation process in React.js.

✏️ Texture Baking for Procedural Materials

In a nutshell, Blender provides the flexibility to employ procedural nodes for your materials. While these nodes function seamlessly within Blender, they are not directly compatible with other game engines or software frameworks such as Three.js.

To learn more, consider watching the following video. In just 10 minutes, it demonstrates the process of texture baking, which effectively resolves the issue at hand.

Personally, when confronted with this challenge and initially uncertain about its nature, I found this video to be a valuable resource for gaining deeper insights into the subject matter.

In our specific scenario, while we might not encounter as complex a situation as seen in the video, we are still faced with the use of nodes that lack direct compatibility with various software tools.

Next, we'll briefly walk through the steps mentioned in the video. However, if you're interested in delving deeper into this process, I highly recommend watching the video.

How to create an image texture node

To start, in the Shading tab for the material containing the Glossy BSDF node, we'll introduce an Image Texture node and connect it to a new image (by click on New).

We'll leave the settings at their default values, which means a width and height of 1024px. Using larger values would considerably extend the processing time we're going to face. Still, it's important to note that a larger texture can offer more detail and an overall improved appearance.

In our current situation, we're aiming for a quick process. But for more significant projects, visual quality might be crucial. In such cases, opting for a higher resolution could be desirable.

Creating an Image Texture node and assigning a new image to it with default settings

How to apply the Smart UV Project process

Next, we need to employ the Smart UV Project option located in the UV Editing tab. Essentially, this action unwraps the faces of the particular object onto a texture.

This process enables us to specify which parts of the texture should be colored and modified as soon as we are back in the Shading tab. To make this process effective, we must select all the faces of the large sphere.

Selecting all faces of the object in the UV Editing tab and applying Smart UV Project on it

Once we've finished this step and utilized the default settings for the Smart UV Project procedure, the image on the left —previously featuring a grid— will now display the shapes of the sphere we applied this process to. In our situation, it seems like the texture captured various angles of our sphere.

The texture after Smart UV Project

Depending on the specific object, you may need to fine-tune the settings presented after clicking the Smart UV Project button. If you encounter challenges with a particular object, the video I shared earlier can give you additional guidance on this aspect.

Generally, to mitigate issues, you should optimize your object layout during its creation phase. Avoiding the introduction of excessive edges in specific locations can prevent problems like clipping, for instance.

The Bake process

Now, let's return to the Shading tab, where we'll access the Render Properties on the right side (represented by the small screen or TV symbol). If not already selected, pick Cycles as your Render Engine. Then navigate to the Bake category, which is located below the Performance category.

Bake option in the Shading tab within the Render Properties

With the existing default settings, you can proceed by clicking the Bake button while ensuring that both the Image Texture node and the large sphere are selected.

Keep in mind that I integrated a Sun light into my scene, as this bake process takes the scene's lighting into account. Without sufficient lighting, the result might appear excessively dark.

After a period of processing (which might be more time-consuming if you've employed larger dimensions for the Image Texture node's image), the baking process will finish. This results in the texture being applied to the image from the Image Texture. Instead of obtaining the texture from the Shader node named Glossy BSDF, we now have access to it through a regular "normal" image texture.

Then we can establish a connection from the Image Texture node to the Material Output node, thereby successfully implementing our material. At this stage, there isn't a significant difference compared to the previous method where we had the Principled BSDF node connected to the Surface input of the Material Output node.

Image Texture node with the "baked" texture is connected with the Material Output node instead of the Glossy BSDF node

How to see the final result

Now, we can export the file again, repeat the same process from before in our IDE with glTF Tools and view the .gltf file with the extension. Upon examining the outcome, you might notice that it's not an exact match to the version we had using the Glossy BSDF node in Blender. This difference can be primarily attributed to the lighting conditions in the Blender scene.

Bear in mind that the approach I've outlined isn't the typical usage for the baking process, since in this case you could also just have picked a similar base color with the Principled BSDF node and would achieve pretty much the same solution, for example.

Finalized view with glTF Tools, including the "baked" texture for the large sphere

I introduced the baking process based on personal experience. There were instances where I encountered a scenario where materials appeared differently in Blender compared to when implemented them in a React.js application with Three.js. This situation prompted me to explore the concept of baking, which turned out to be a helpful solution.

To summarize, if you find yourself facing a scenario where your materials don't appear as expected in your React.js application with Three.js, considering the baking process and researching this topic can provide valuable insights. This can be particularly beneficial for people who are new to Blender.

✒️ How to Implement the Blender model in the React.js Application

To implement the Blender file, we can use a really useful shortcut (source: https://github.com/pmndrs/gltfjsx):

npx gltfjsx public/blenderFileName.glb

It's important to note that you need to store your Blender file within the public folder of your React.js application for this step. It's also worth highlighting that you need React Three Drei to use this helper. So in our case, we can directly use this shortcut without the need for any additional preparations.

Upon executing this shortcut, we are presented with the following file:

/*
Auto-generated by: https://github.com/pmndrs/gltfjsx
Command: npx gltfjsx@6.1.4 public/blenderStuff/blenderFile.glb
*/

import { useLayoutEffect, useRef } from "react";
import { useGLTF, useAnimations } from "@react-three/drei";

export function Model(props) {
  const group = useRef();
  const { nodes, materials, animations } = useGLTF(
    "./blenderStuff/blenderFile.glb"
  );
  const { actions } = useAnimations(animations, group);

  return (
    <group ref={group} {...props} dispose={null}>
      <group name="Scene">
        <mesh
          name="Cube"
          geometry={nodes.Cube.geometry}
          material={materials.Material}
          position={[-0.07, 0.16, -0.27]}
          scale={[1, 0.03, 1]}
        />
        <mesh
          name="Sphere"
          geometry={nodes.Sphere.geometry}
          material={materials["Material.002"]}
          position={[-0.62, 0.43, -0.79]}
          rotation={[-0.01, 0.11, -0.02]}
          scale={0.09}
        />
        <mesh
          name="Sphere001"
          geometry={nodes.Sphere001.geometry}
          material={materials["Material.001"]}
          position={[0.4, 0.55, 0.15]}
          scale={0.41}
        />
      </group>
    </group>
  );
}

useGLTF.preload("./blenderStuff/blenderFile.glb");

At first glance, you can see that this process has added many elements, so we basically don't need to add much on our own.

An important aspect to configure is the path within the useGLTF hook. In my instance, the accurate path to incorporate is ./blenderStuff/blenderFile.glb (this applies to useGLTF.preload() as well). This is because I created a sub-folder named blenderStuff within my public directory.

How to add a Canvas wrapper and other components

With this configuration in place, we're now ready to use the Model component. But to effectively integrate this Model component into our desired location, we need to make some adjustments in the parent component.

In my case, I've opted to implement it within the main App.js file. And I've assigned a height of 100vh to the App's CSS class to ensure the desired display.

import "./App.css";
import { Model } from "./BlenderFile";
import { Canvas } from "@react-three/fiber";
import { OrbitControls } from "@react-three/drei";

function App() {
  return (
    <div className="App">
      <Canvas camera={{ fov: 64, position: [-2, 2, 0] }}>
        <ambientLight intensity={5} />
        <OrbitControls enableZoom={true} />
        <Model />
      </Canvas>
    </div>
  );
}

export default App;

Generally speaking, you'll need a component to encapsulate all the Three.js related elements. Within the Canvas component, there's an opportunity to configure various settings. In my specific instance, I'm adjusting the initial camera position.

The light for the component plays a crucial role. In our case we made use of ambientLight which will add a light to the whole scene. Without adequate lighting, your scene might appear exceedingly dark or even entirely black despite the presence of object colors. You can also use additional light sources like the spotLight component.

The OrbitControls component, accessible from the Drei helper library, enhances your interactivity by enabling scrolling and rotation within the model right within the browser. This single line of code substantially improves user interactivity options.

Remember that your Canvas component can accommodate multiple models. You can also selectively apply components like OrbitControls to specific Blender models, thereby tailoring their behavior.

To do this, you'll need to build a parent component for each scene you want to make to be integrated within the Canvas. Within each new parent component, incorporate your Blender model component, along with any supplementary helper components you want to add.

This approach proves particularly advantageous when distinct models require different lighting or unique camera positions, for example.

How to implement the animations

At this point, we've established a functional Three.js Canvas environment, featuring our Blender model. But it's important to remember that we've also introduced basic animations, which are not yet operational.

To tackle this, we can leverage the pre-implemented useAnimations hook.

  const { actions, names } = useAnimations(animations, group);

  useLayoutEffect(() => {
    names.forEach((animation) => {
      actions?.[animation]?.play();
    });
  }, [actions, names]);

By incorporating this implementation, all animations associated with this Blender model will start playing upon the rendering of the page. This behavior also includes an indefinite loop for each animation.

📄 Additional Information

While this tutorial primarily focused on integrating a Blender model into a React.js application using Three.js, there's a realm of untapped potential within Three.js that we didn't cover.

Although we didn't use it in this basic example, you can introduce Post Processing to your Three.js models within React.js. The React Three Postprocessing library serves as a valuable tool in this regard. It lets you elevate your Three.js scenes with sophisticated effects like Bloom or Noise effects, which can add a more advanced dimension to your visualizations.

Also, when working on future Three.js projects, consider exploring the React Spring library which integrates well with React Three Fiber. React Spring provides the opportunity to incorporate custom animations within your Three.js scenes, on top of any animations directly integrated within Blender.

For instance, you could make a specific object within your scene get larger or smaller upon clicking it. As with other aspects of Three.js, this aspect might enhance interactivity and might be worth your time to get into.

By the way, if you find that your frames are running at a lower rate, consider toggling Hardware Acceleration within your browser settings to potentially improve performance.

📋 Wrap-up

At this point, we've successfully crafted a Blender model with animations and materials. Afterwards we integrated it into our React.js application using React Three Fiber.

Although the example we looked at here was quite basic, the integration approach remains the same for more complex Blender models. The fundamental functions of Three.js can be combined with supplementary helpers to enhance your scenes.

In addition to Post Processing, additional animations or also specific Blender materials, aspects like cameras and lights often are the most important when aiming to enhance the visual impact of your Blender models within Three.js scenes.

🔐 Here's What We'll Cover

• You'll see how easy it is to set up your first unit tests in React.
• You'll improve your general React knowledge.
• You'll get the hang of why Test Driven Development (TDD) is helpful for your coding workflow.

📝 Prerequisites

• You should be familiar with the basic React workflow structure (including functional components and hooks).
• You should have a basic knowledge of Redux (I'm using Redux Toolkit for this guide).
• You don't need any prior knowledge about testing.
• I'm using the npm installation approach, not the yarn one.

🎯 The Objective

While learning advanced concepts of React, you'll probably stumble across the topic of testing. Being able to work with automatic tests is also quite handy for any upcoming frontend developers.

However, as I myself was learning React, I had a hard time finding information about how to implement tests for libraries like Redux (even though it's a library I work with all the time).

Beyond that, I found that doing any component testing in React is basically unfeasible when you don't know how to work with the Redux library.

So I took some time to read the Redux documentation and went back and forth with it a bit. Then I decided to write a practical starter guide for unit testing in React, including Redux, to share what I learned.

Since I would like to take a modern approach, I'm also going to use the Redux Toolkit. We'll cover the Redux implementation in this guide.

What we'll cover:

To start off, I will provide some general information about tests before I directly go into creating the first general unit tests.

Next I'll give a quick overview of how to implement some Redux Toolkit logic.

Then we will work on some unit tests within an application which uses Redux Toolkit. For this step we will adjust our previously created tests to the new Redux environment.

This is a step-by-step guide. If you are new to tests, I recommend following this guide in order from top to bottom.

I have also created a public GitHub repository for this guide with some commentary. You can use that if you want to look something up without scrolling through this guide in its full length again.

Table of Contents

1. What Different Kinds of Tests Are There?
2. How to Set Up Your React Testing Environment
3. Check Out Your Created React Application
4. How to Create Your First Unit Test
5. How to Create a Failing Test on Purpose
6. How to Create Some Additional Tests
7. How to Perform Testing with the React Redux Toolkit
8. Outlook for Advanced Testing

📋 What Different Kinds of Tests Are There?

This quick guide won't provide you with detailed theoretical knowledge about all the different kinds of testing out there. At this point, you should just understand that there are generally three kinds of tests:

• Unit Tests
• Integration Tests
• End-To-End Tests

To put it in simple words: You can see these three types of tests as generally increasing in their complexity.

While unit tests cover single functions and components, integration tests typically focus on multiple functions and their connections to each other. End-to-end tests are even more complex and give insights about multiple function and component structures.

There are other test concepts, but these three are the most important ones for web developers, for example.

Again, this is really put in simple words. But in this case it's sufficient to know that unit tests are basically the least complex tests out of these three.

It's also quite easy to work with unit tests as soon as you have a basic understanding of how testing in general works.

I would also like to quickly emphasize that there are mainly two ways of testing your application.

• Manual Testing
• Automatic Testing

Manual Testing is pretty much what you probably already do for all of your application which you create. When manually testing your application, you basically start your React application with npm run start and actually click on buttons to check if the corresponding function works.

Automatic Tests, on the other hand, are pretty much functions you create which automatically check your application to see if the respective steps work that you defined within these tests. This automatic kind of testing is extremely important for larger projects.

With this automatic approach, it's also way easier to scale your tests. In the end, you have a lot of tests which automatically test your whole application in a relatively short amount of time. These test can help you spot any potential errors which might have occurred during development. This would take much more time if you were to go back constantly to manually test your application.

Being able to work with automatic tests is also typically a big plus for your résumé as a frontend developer.

🔧 How to Set Up Your React Testing Environment

In order to get a practical start, we are going to directly dive into our React application.

You will see that the setup of a testing environment is relatively easy in React – or, to be more precise, React does it all for you during the regular install setup.

Therefore, I'm creating a React application with the following line:

npx create-react-app <name of your application>

After this step, we need everything that should be added for using Redux in our React application:

• React Redux: npm install react-redux (provides some mandatory hooks, for example)
• React Redux Toolkit: npm install @reduxjs/toolkit (provides logic for creating a store or slices, for example)

It's worth mentioning that there also is the Redux core (npm install redux). But this is already part of the React Redux Toolkit installation, so we don't have to install it here too.

If you wanted to use React without the React Redux Toolkit, then you would have to separately reach out to the Redux core installation.

You can also create a new React application from scratch with npx create-react-app my-app --template redux which includes the React Redux Toolkit, the React core, React Redux, as well as a template from the React Redux Toolkit.

Choose this approach if you don't have any existing React applications, since it's probably more convenient.

Under the hood, you now have an application that uses the React Testing library combined with Jest (a testing framework). Together, they have pretty much everything that you will need for testing your React application.

You don't have to install anything else for this purpose. These tools come out of the box with a standard React installation.

🔎 Check Out Your Created React Application

As you go into your newly created React application, you will find the folder and file structure you are likely familiar with. Besides others, there is the App.js file, which is created like this:

import logo from './logo.svg';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App;

Within the src folder, you also have the file App.test.js. This file is actually a first test that came out of the box with React installation. This file is structured like this:

import { render, screen } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});

Even without fully understanding what render or screen is, for example, we can see that something is going on with our App component in there. In fact, this is a unit test that is focusing on a specific part of the App component.

While this first template for a test is a handy representation of what a test looks like, I would like to create a test file from scratch.

Generally speaking, tests are separated into different test suites. These test suites are typically a group of tests that focus on the same component, for example. Tests within the same test suite basically have the same superordinate topic.

To check this, try to enter npm run test in your terminal when you are within your React application.

It could say something like "There are no new tests or changes since the last commit" – in this case, just enter a in the terminal to run all tests regardless.

In the end, you should be able to see this within the terminal:

Result of npm run test

At the top, you can see that the App.test.js file passed. Basically, all tests within this file were successful.

Below that, you can see renders learn react link: This is the description for this particular test, which we can define individually. We will get back to this later.

Further down, we can finally see the test suites and tests. As you can see, we have one test suite and one test. To be more precise, we have one test suite that includes this one test.

Later on, you will recognize that we will use like 1-3 test suites while there will be around 5+ tests, for example. Again, test suites basically provide a structure that groups single tests together.

The stuff with the snapshots is not important for your specific case.

Snapshots are an advanced concept for testing. So a reference snapshot (like an image that was taken) is being compared with the version after some actions took place. This can help to check whether the UI stays the same after some actions or if some changes happened all of a sudden.

I won't focus on testing with snapshots in this article. This is a topic that you might want to look up after understanding some unit testing basics.

🔨 How to Create Your First Unit Test

Now that we've looked at a unit test, lets dive into the first test which we'll build from scratch on our own.

For that, I would like to create a new folder called __tests__. This is common when you are working with tests or checking out other applications.

I'm also dragging the already-available App.test.js file into this folder. This doesn't change anything about the result.

Our folder structure now looks like this:

general folder structure with __tests__

Within __tests__, we create the file myFirstTesting.test.js. We need this file structure of <test name>.test.js. You can also create a test file with <test name>.spec.js – both approaches will work the same.

Our first step is to import the App.js component: import App from "../App";.

To create our first test, we have to make use of the test() function. You could also use it(). Both will achieve the same result.

The first parameter of this function has to be a string, which describes what we are going to test (remember the stuff with "renders learn react link" within the test file we viewed?). This is going to help you have a more precise overview after running all the tests.

In this case, I will use the description "renders logo in App component". The second parameter is another function for which we are using an anonymous arrow function. Our myFirstTesting.test.js file now looks like this:

import App from "../App";

test("renders logo in App component", () => {

})

Even though there is not much going on, let's try entering npm run test again. We will find the following result in our terminal:

Therefore, we now have two test files, resulting in two test suites and two tests.

Now we would actually like to test something. Since we added the description "renders logo in App component", we are going to test exactly that.

In order to do that, we need the render() function, which we'll use whenever we actually want to render a component from our application.

In order to add the render() function, we have to import it from the React Testing library, which is already part of our React application without any other installations.

While we're at this step of importing, let's also import screen (also part of the React Testing library). It provides access to different functions that will look through the current screen after something gets rendered and find specific elements, for example.

After adding these two imports, our myFirstTesting.test.js file now looks like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

test("renders logo in App component", () => {

})

Now that we have all that, let's actually start working on our test.

First of all, we need to render our component. Remember that tests are self-contained and don't know that we have an App.js with the corresponding content in our React application. We have to individually tell the specific test that a component exists by rendering it with render() at the top of the test. This is going to look like this: render(<App />);.

Now that we have rendered the App.js component in this test, we should try to check if a specific content part can be found by the test. This way, we can actually test if App.js was rendered like it was supposed to be.

Assuming something went wrong, we would not be able to find the React logo, for example, which is currently part of the App.js component.

So we will try to find this logo, which is an img element. To do this, we can make use of the getByAltText() function that finds an element by its specific alt attribute, which is commonly utilized for images. We have access to this function with screen that we imported earlier.

We now have this expression: screen.getByAltText("logo"). So the test looks at the screen where we rendered the App.js component beforehand, and then gets an element, which has an alt attribute of "logo". We will connect all this to a variable.

Our test file now looks like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

test("renders logo in App component", () => {
  render(<App />);
  const image = screen.getByAltText("logo");
})

There are a bunch of different functions like getByAltText() that you can use to look for elements with a specific text content, a specific role like a button, or even with a test id that you can add to the actual element.

You also have the opportunity to look for multiple elements. Besides that, you don't have to use a string as parameter. A regular expression with /logo/i is also feasible, for example. We will use different ways to find elements throughout this starter guide.

For the last step, we have to utilize expect(), which we use to see what behavior we can expect. In this case, we expect that our image variable is part of the component and therefore exists.

For this approach, our file would look like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

test("renders logo in App component", () => {
  render(<App />);
  const image = screen.getByAltText("logo");
  expect(image).toBeInTheDocument();
})

❗ How to Create a Failing Test on Purpose

If we now run our tests with npm run test, everything will pass. Now, let's try to reverse this logic so that we actually create a failing test. This way, we can check if this test actually has some impact or not.

To do this, we can go into our App.js file and change the alt attribute for the logo image. If you change it to alt="loo", the test will fail and it'll give you some information.

In our case, though, I would like to change something on the test itself to make it fail and show you another expression that is handy to know. Instead of expect(image).toBeInTheDocument(); we can also type expect(image).not.toBeInTheDocument();. So here we added a not. This basically reversed the logic, and now the test expects that no such image element exists.

If we now try to run the test, we will find the following error message in our terminal:

The error message we get

You can see that the test expected that there was no such element as image. However, it found something and therefore answered with an error message.

You don't have to make all your tests purposely fail to check if they work or not. I just wanted to show you what an actual failing test would look like.

✏️ How to Create Some Additional Tests

Now we have finished with our first test and have some basic knowledge about what to expect when working with unit tests. Next, we will check out some other test examples.

In order to create a more realistic scenario, I will add one additional component, which we'll insert into the App.js component.

For this step, first we create a folder called components in our src folder. This is not a must, but it is common to structure your files like that.

Within the components folder, we create List.js. Our folder structure now looks like this:

current folder structure

Now, let's try to follow more of a test driven development (TDD) workflow, which is quite modern. I'm not necessarily sayint that this is always recommended. But a TDD approach is considered best practice by more and more people nowadays.

Of course, in this tutorial we'lre "only" talking about unit tests and not integration or end-to-end tests, but the general TDD workflow is similar for all three test categories.

So using this test driven development approach, we basically add tests and work on our application simultaneously.

To be more precise, we even create tests for single components and function parts before you even implement this tested logic in your application.

So there is a lot of going back and forth instead of creating all the tests at once at the end.

How to Start the Setup for List.js

In our example, we have added the List.js component. Within this component, I would like to add a list with a button. When a user clicks on the button, it adds something to the list (an object with multiple keys and values).

In order to have some sort of frame, I will first add some div elements and similar stuff to our List.js component before we dive into the actual logic.

The List.js component now looks like this:

const List = () => {
  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        <li>This is the first list entry</li>
      </ul>
      <button>This button can add a new entry to the list</button>
    </div>
  );
};

export default List;

I also added the List.js component as a child to App.js (below all the other stuff in App.js) so it will be visible without changing anything else.

The result looks like this:

How it looks

This won't win you any style competitions but it's sufficient for our case.

Setup for the test for List.js

Since we want to test while we are working on our component, I will now jump directly to the testing part even if nothing really happened in our List.js component in terms of click functions, for example.

We could create a new test file, but I would like to show you a new function we can use for our test suites specifically. This function is called describe() and can be handy for further structuring our tests.

To use describe(), we jump to myFirstTesting.test.js within __tests__. Right now, this file basically serves as one test suite for the test we specifically created for the App.js component. But I would like to have two test suites within this test file: one for the App.js tests and one for the List.js tests.

For this step, I'm using the describe() function, which basically works like the test() function in terms of parameters.

The first parameter will be a string, describing the respective test suite. The second parameter is a function, which then includes our test() functions with their stuff.

It will look like this in our case:

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    expect(image).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("example", () => {});
});

Before we jump into this new test, I would actually like to add something for the App.js testing. Since we have this describe() block, we could just add a new test() function – and this is what I'm going to do.

See the following newly added test described with "renders List.js component in App.js":

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    expect(image).toBeInTheDocument();
  });

   test("renders List.js component in App.js", () => {
    render(<App />);
    const textInListJS = screen.getByText(/This is a list/i);
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("example", () => {});
});

So I'm rendering the App.js component and looking for text via a regular expression, which is part of the List.js component. This test can basically be understood as a render test for List.js. If List.js had not been able to be rendered within App.js, this test would not pass.

If you are confused that this works without separately using render() on the List.js component, remember that List.js is part of App.js and everything inside App.js will be rendered under typical conditions. If you tried to look for a text phrase that doesn't exist in List.js, this new test would fail. Right now, in our case, it passes.

I would also like to emphasize that you can have multiple expect() functions within the same test. Therefore, we also could have structured this new test like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    const textInListJS = screen.getByText(/This is a list/i);

    expect(image).toBeInTheDocument();
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("example", () => {});
});

This would also work perfectly fine in our case. And this can be handy in situations where you test for some small elements which are directly connected to each other and have the same requirements to be rendered.

But keep in mind that in our case, we should have adjusted the description for this test. That's because "renders logo in App component" is not correct anymore if we are testing more than that in this test. So let's head back to the structure with two separate tests for now. But have in mind that you are able to work like this.

Back to the test for List.js

Now I would like to work with the second describe() block that we created a few moments ago, where we want to work with tests specifically for the List.js component.

Since we are aiming for a test-driven development approach, we should think about what we are going to build, write a test, and then implement that logic in our component.

We want to create a simple list in our List.js component. So there will be an array, which we will go through with map().

For this approach, we will utilize the useState() hook so we have a state that can dynamically adjust (the array of list items). Our first test will be to check if the length of this array in its initial state is equal to 1.

To find the items within this state, we will make use of the getAllByTestId() method, which allows us to search for specific elements we marked with a data-testid in the frontend.

The test with the description "renders initial state of listData state" that I created is now included:

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    const textInListJS = screen.getByText(/This is a list/i);

    expect(image).toBeInTheDocument();
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
   test("renders initial state of listData state", () => {
    render(<List />);
    const list = screen.getAllByTestId("list-item");
    expect(list.length).toEqual(1);
  });
});

Right now this test will fail, of course, because we haven't added any of this logic to the component yet.

So I adjusted the List.js component. It now looks like this:

import { useState } from "react";

const List = () => {
  const initialState = [
    {
      id: `${new Date().getSeconds()}`,
      description: "This is something",
      significance: 7,
    },
  ];
  const [listData, setListData] = useState(initialState);

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listData.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button>This button can add a new entry to the list</button>
    </div>
  );
};

export default List;

Newly added was the listData state array via a useState() hook as well as an initialState, which I initialized with one object at the very top. I also made use of the map() function to go through this listData to create a list.

For each <li> element, I'm adding a key and a data-testid. This data-testid is the id we need for our test to find the respective elements.

On our actual application, we can see the listItem.description for this initial state:

So by manually testing (actually looking at our application in the browser), we can see that this should work. If we now run our tests, we will also see that the test we created passed.

How to add an object to the state

Now let's test something more exciting: the logic to add a new object to this listData state. Again, we will start by working on our test first before actually implementing the required logic within the React component.

With this newly added test described by "adds a new data entry to listData after button click", our test file now looks like this:

import App from "../App";
import List from "../components/List";
import { render, screen } from "@testing-library/react";

import userEvent from "@testing-library/user-event";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    expect(image).toBeInTheDocument();
  });

  test("renders List.js component in App.js", () => {
    render(<App />);
    const textInListJS = screen.getByText(/This is a list/i);
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("renders initial state of listData state", () => {
    render(<List />);
    const list = screen.getAllByTestId("list-item");
    expect(list.length).toEqual(1);
  });

  test("adds a new data entry to listData after button click", () => {
    render(<List />);
    let listItems = screen.getAllByTestId("list-item");
    const button = screen.getByRole("button", {
      name: /This button can add a new entry to the list/i,
    });

    expect(list.length).toEqual(1);
    userEvent.click(button);
    list = screen.getAllByTestId("list-item");
    expect(list.length).toEqual(2);
  });
});

At the bottom, you can see this test. Therefore, we are first rendering the List.js component before looking for all available list items we assigned a test id to. You will see exactly where we put the test id in a few moments.

We also have to look for the button that we want to test to see if clicking on it adds something to the list. We do this with getByRole() which expects a role like "button" or "table" as a first parameter, for example (there are a bunch of different roles you can target). The second parameter is optional and is an object that can receive a value for the name key.

name is pretty much the text content we have specifically for the button in this case. This optional second parameter is handy when you have multiple elements of type "button" in your component and want to get a specific button out of these.

After getting the listItems as well as the button, we start off with a first expect() to basically test the initial state. In this initial state, we expect to have only one list item.

Then, with the help of userEvent, we are going to click on the button. You could also use fireEvent for this situation (userEvent is still pretty new compared to the fireEvent approach). Both will work, and both are helpful for any action where you want to interact with specific elements. In this case, I want to simulate clicking on a button.

Tests generally follow a "arrange -> act -> assert" pattern that you can follow to structure them. Within the "arrange" part, you initialize and get all required elements. With the "act" part, you would simulate a mouse click (as in our case), for example. With "assert," you are checking if it all behaves like you expected it to.

In another case, you could simulate changing the value of an input field with fireEvent.change(inputField, { target: { value: someValueVariable } }), for example. Maybe you want to focus an input field or even drag an element - such actions can be simulated via fireEvent and userEvent.

After the button click, it again looked for all listItems since the current value of this variable would still be 1 from the previous initialization. As soon as this step is completed, it uses another expect() function to check if the length of the listItems array is now equal to 2 and not 1.

Now that we have our test logic, let's jump back to the List.js component and implement the corresponding logic:

import { useState } from "react";

const List = () => {
  const initialState = [
    {
      id: `${new Date().getSeconds()}`,
      description: "This is something",
      significance: 7,
    },
  ];
  const [listData, setListData] = useState(initialState);

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listData.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button
        onClick={() =>
          setListData([
            ...listData,
            { id: 999, description: "999", significance: 100 },
          ])
        }
      >
        This button can add a new entry to the list
      </button>
    </div>
  );
};

export default List;

The only part that changed is the button at the bottom of this file. So I added a function that gets invoked when clicking on this button. The function then adjusts the current state of listData which is responsible for rendering our list. I copied the current state with a spread operator and then added another hard-coded object as the new entry for this list.

Of course, there are more creative ways to fill in the values for the id, description, and significance keys.

I would also like to emphasize that you have the opportunity to create a separate function outside of the return() and access this function like this: onClick={separateFunctionToAddObjectToState} on the same button element. This would also work without having to render something additional within the test.

If we now run our test, we will see that it passes. If you try to still expect a length of 1 after clicking on the button, the test will fail like this:

error alert for length of 1

So it actually does what it is supposed to do.

🔧 Setup for Redux

After working with local states via the useState() hook, I would like to work on the same files and adjust them for Redux (or the Redux Toolkit, to be precise).

I'm not going to dive deep into what Redux actually is and what every term like action, store, or reducer means in detail – since this would be worthy of a whole new guide. If you want that, you can read this guide to Redux basics.

Instead, I will give just a quick rundown and show which files I'm adding and editing. Then I'll talk about how to handle the render() method, including the Redux store provider, which can cause a lot of frustration when testing if you don't know about it.

Overall folder structure:

current overall folder structure with the React Redux Toolkit

You can see that I added an app (for the store) as well as a features (for the slice) folder.

Updated index.js file:

import React from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import App from "./App";
import reportWebVitals from "./reportWebVitals";
import { Provider } from "react-redux";
import store from "./app/store";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>
);

You can see that I added a provider and wrapped it around the application so we have access to the store from anywhere.

Created store.js file:

import { configureStore } from "@reduxjs/toolkit";
import { ListSlice } from "../features/ListSlice";

const store = configureStore({
  reducer: {
    listReducers: listSlice.reducer,
  },
});

export default store;

In this file, we have created the required store for the Redux implementation.

Created ListSlice.js file in features folder:

import { createSlice } from "@reduxjs/toolkit";

export const initialState = {
  value: [
    {
      id: `${new Date().getSeconds()}`,
      description: "This is something",
      significance: 7,
    },
  ],
};

export const ListSlice = createSlice({
  name: "listReducers",
  initialState,
  reducers: {},
});

export const { } = ListSlice.actions;
export default ListSlice.reducer;

Here we have created the slice that we added to the store. Notice that I haven't added any reducer yet. This slice just contains the current corresponding state.

Updated List.js file in components folder:

import { useSelector, useDispatch } from "react-redux";

const List = () => {
  const listState = useSelector((state) => state.listReducers.value);
  const dispatch = useDispatch(); // not used right now

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listState.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button>This button can add a new entry to the list</button>
    </div>
  );
};

export default List;

On the frontend, we swapped the local state (using the useState hook) with the Redux state (using the useSelctor hook). You'll also see that I adjusted the button. There is no click function anymore (we will get back to that later on).

🔎 How to Perform Testing with the React Redux Toolkit

Now that we have updated and created all the necessary files for the React Redux Toolkit logic, I would like to run a quick test of all the tests we previously created.

The result is that all tests have failed:

Keep in mind that I adjusted the button in List.js, for example, so the corresponding test was expected to fail. However, not all tests should have failed.

The test environments are working in their own world. They don't know if you wrap a provider somewhere in index.js and enable Redux logic. So the tests are still trying to make the rendering work without Redux. But our application now depends on Redux to manage our main state.

This means that we have to adjust the render() function so that this function is actually aligned with the Redux logic.

A method to make this work is to introduce a helper function, which we will store in a new folder called utils. The file will be called utils-for-tests.jsx. The content will look like this:

import React from "react";
import { render } from "@testing-library/react";
import { configureStore } from "@reduxjs/toolkit";
import { Provider } from "react-redux";
// As a basic setup, import your same slice reducers
import { ListSlice } from "../features/ListSlice";

export function renderWithProviders(
  ui,
  {
    preloadedState = {},
    // Automatically create a store instance if no store was passed in
    store = configureStore({
      reducer: { listReducers: ListSlice.reducer },
      preloadedState,
    }),
    ...renderOptions
  } = {}
) {
  function Wrapper({ children }) {
    return <Provider store={store}>{children}</Provider>;
  }

  // Return an object with the store and all of RTL's query functions
  return { store, ...render(ui, { wrapper: Wrapper, ...renderOptions }) };
}

This code information can be found in the Redux documentation. You can almost copy and paste it all for your application.

But you have to adjust the slices that are used in there. Since in our application there is only the ListSlice we don't have much to add. Just import that and update the content of the configureStore() function, like we managed it in our store.js file.

This step is necessary to basically mock the entire Redux logic and put it together into one new render() function.

With that, we can import this new function into our test files (App.test.js and myFirstTesting.test.js) and then replace all render() functions with renderWithProviders(). The App.test.js file, for example, now looks like this:

import { screen } from "@testing-library/react";
import App from "../App";
import { renderWithProviders } from "../utils/utils-for-tests";

test("renders learn react link", () => {
  renderWithProviders(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});

There is not much more to do! If we now run our tests again (and comment out this one test, which is going to fail regardless because the button logic is not active anymore), it will work again.

Slice testing

Another exciting part about testing with Redux is testing the slices. If you created your application with the React Redux Toolkit template, then you will be provided with some corresponding tests.

For our case, I also want to implement a new test file where we will specifically test ListSlice.js and its corresponding Redux logic.

For this slice, we have to import the slice and the corresponding reducers we want to test. To start, I will import the slice and test if it gets initialized with the initialState.

This is actually not the TDD approach since we already manually tested this part. Netherless, I would like to implement an automatic test as well:

import ListSlice, { initialState } from "../features/ListSlice";

describe("tests for ListSlice", () => {
  test("initialize slice with initialValue", () => {
    const listSliceInit = ListSlice(initialState, { type: "unknown" });
    expect(listSliceInit).toBe(initialState);
  });
});

Notice that I'm using .spec instead of .test. This doesn't matter. You can choose either. In this case, I'm going with .spec to remind you that this is also a viable option.

Also remember that we exported the initialState within our slice (see above). So we are able to import it here.

Other than that, we are already familiar with the describe() environment, which includes one test(). Within this test, I'm initializing a variable listSliceInit, which will hold the value we are receiving after the slice operation took place.

For this operation, we use ListSlice as a function and include the initial state as the first argument (in this case initialState). The second argument will be a reducer in most cases.

But in this case, we don't need to enter a reducer. Instead, we are using an object with type: "unknown". This is basically telling the function that we don't want to perform any additional operations.

Therefore, listSliceInit should now include our state value, which includes an array with one entry. The corresponding test will pass.

To force a failure, I'm entering expect(listSliceInit).toBe({ value: [] }); instead of the previous expect() function. So instead of our initialState we are expecting it to have an empty array. Now our test environment will tell us the following:

failing test

So it actually tells us what exactly it expected – in this case, it expected the initialState.

Next, I would like to test a reducer. However, we haven't added one yet. So I will adjust ListSlice in the ListSlice.js file like this:

export const ListSlice = createSlice({
  name: "listReducers",
  initialState,
  reducers: {
    testAddReducer: (state, action) => {
      state.value.push(action.payload);
    },
  },
});

Thus, I added testAddReducer(), which is responsible for pushing one additional element to the current state value, which it receives via an input from the dispatch (through action.payload).

If we now jump back to the listSlice.spec.js file, I'm adding another unit test:

import ListSlice, { initialState, testAddReducer } from "../features/ListSlice";

describe("tests for ListSlice", () => {
  test("initialize slice with initialValue", () => {
    const listSliceInit = ListSlice(initialState, { type: "unknown" });
    expect(listSliceInit).toBe(initialState);
  });

  test("testAddReducer", () => {
    const testData = {
      id: `${new Date().getSeconds()}`,
      description: "This is for the test section",
      significance: 5,
    };

    const afterReducerOperation = ListSlice(
      initialState,
      testAddReducer(testData)
    );

    expect(afterReducerOperation).toStrictEqual({
      value: [initialState.value.at(0), testData],
    });
  });
});

I added the test for testAddReducer. You can see that I imported the reducer as well.

Firstly, I'm initializing a new variable, testData, which contains the data I would like to push to the current state.

After that, we follow the same structure as before with afterReducerOperation. But instead of this type: "unknown" stuff, we add the reducer as the second argument. This receives the testData as a parameter – basically like you would see it in a dispatch.

Then, we expect this afterReducerOperation variable to be strictly equal to the value of an array, which has two entries: initialState.value.at(0) (the first entry of our initialState) and testData. And this test will pass like we actually expected it.

If we are trying to enter some other entries or change the current ones, you would be able to see this test failing:

forced error: I added a third entry to the array

How to make the button click function work again

Remember the button click within the List.js component (for adding something to the listData state) that wasn't working anymore after we changed to the Redux setup? Let's quickly update that to make that logic work within a Redux environment for the sake of completeness. Since we have the required reducer now, this will be an easy step.

To make the test work again, which added a new element to the state, we have to adjust it a little on the frontend to implement the Redux logic. (Previously we used the useState hook for a local state.)

For this step, we are making use of the dispatch() function in order to reach out to the testAddReducer:

import { useSelector, useDispatch } from "react-redux";
import { testAddReducer } from "../features/ListSlice";

const List = () => {
  const listState = useSelector((state) => state.listReducers.value);
  const dispatch = useDispatch();

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listState.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button
        onClick={() =>
          dispatch(
            testAddReducer({
              id: `${new Date().getSeconds()}1`,
              description: "This is added",
              significance: 5,
            })
          )
        }
      >
        This button can add a new entry to the list
      </button>
    </div>
  );
};

export default List;

Besides the button logic, nothing else has changed in this file.

In the corresponding test (within myFirstTesting.test.js nothing has changed), if we now test everything – including this updated test – we will see that everything works fine:

final test run

And that's pretty much it for fundamental slice and general Redux unit testing!

🔭 Outlook for Advanced Testing

There are different topics like thunks (or RTK Query as an alternative) which could also be tested. But I'm considering this as an advanced topic, and it would take some more time to explain these processes.

If you are not aiming to be an expert in testing at this point, the topics we discussed for unit tests in Redux in this tutorial should be sufficient for you.

Generally speaking, I would recommend diving deeper into so-called mocks, spies, and also snapshots. These will be helpful if you are working on some other more advanced tests.

The stuff with renderWithProvider() is basically based on such a mock – there, we artificially created a store with reducers and a provider to create this new render() function. So mocks are especially helpful for any third-party libraries, for example.

As I said, though, mocks, spies, and snapshots are more of an advanced topic to wrap your head around.

📣 Further Learning Opportunities

I recently started to work on my first free Udemy course. While this first free course covers the basics of the React Redux Toolkit with German audio and manually added English subtitles, I'm also planning to publish other Udemy courses completely in English in the future.

I would really appreciate it if you would check out this cost-free course in order to provide me with some feedback.

🔐 Here's what we'll cover:

• You'll get to know getStaticPaths(), one of the core principles of Next.js.
• You'll improve your general Next.js knowledge and confidence.
• You'll have access to a quick-replicable example for your own Next.js learning purposes.

📝 Prerequisites

• You should be familiar with what Next.js is and why you should consider using it.
• You should have some understanding of what Routing and Dynamic Routing mean in React and/or Next.js.
• For this example, I work with TypeScript. But it's not necessary for you to be familiar with TypeScript. I will address the code which would be omitted when using JavaScript. Also, whenever you see .tsx regarding any files, you can just replace that with .js if you are using JavaScript.

🎯 The Objective

This quick guide aims to help you manage fetching data, which can be used for pre-rendering purposes within dynamic routes in Next.js. We'll discuss some theory as well as a practical example.

While we are focusing on the actual logic of the required code, I won't do any CSS styling whatsoever. Feel free to get creative on the frontend for your own project when you're using the techniques we discuss in this tutorial.

🔎 How Routing Works in Next.js

While React itself uses a code-based approach for any routing intentions, Next.js utilizes a file-system for the concept of routing.

Therefore, you are probably familiar with code-based routing in React, which may look similar to this:

Example for code-based React Routing

With this code-based approach, you are, for example, able to navigate from the main route at / to the about page through /about.

You are also able to find a dynamic routing approach in this React example with the :productId path.

With Next.js, though, we don't use such code-based routing anymore. Instead, this React framework makes use of file-based routing. This means that you set up your routes directly through page files.

Consider the following pages folder containing subfolders and files:

Example for file-based Next.js Routing

The index.tsx file would be the equivalent to the / path in the React Routing example from above. So you would be able to reach the content within the user-profile.tsx file through /user-profile – that's it!

On the other hand, if you want to reach out to some nested content, you can use /stars/[id] in order to find the content in the corresponding page file.

Maybe you noticed that I'm using square brackets for [id].tsx as well as for [something].tsx. That's needed in order to set up dynamic routing in Next.js.

You could technically insert any input you would like for [id] and the page would load for this specific path.

Just keep in mind that if this dynamic route requires a valid input for [id] (maybe some sort of existing product id for which we want to fetch the respective data), then there could be an error.

✂️ Data Fetching in Next.js with Dynamic Routing

Imagine you apply this dynamic routing approach to a shop page where you list a bunch of different items. Each item would have a link for more information about that specific item.

Within this Link element, you would be able to lead the user to a dynamic route with a valid parameter (the corresponding product id, for example). For such cases, dynamic routing is the best approach.

❗How does getStaticProps() work?

With this function, you can pre-render a page at build time. This is useful for Search Engine Optimization (SEO) purposes, for example, and can overall generate a better user experience.

The data which should be pre-rendered can typically be found on some database, for example. Like with getStaticProps(), you are able to directly write any server-side code within this function for data fetching purposes (instead of reaching out to an API route on the backend, which then goes through any required server-side actions).

There is more to say about getStaticProps(). If you are pretty new to all this stuff, I highly recommend checking out the official Next.js documentation on this topic.

❓ What's the purpose of getStaticPaths()?

While getStaticProps() on its own seems to already do all the work we need to be done for our pages, we will encounter an error when we use this function alone on dynamic routing pages. The error message will actually call you out on this specific fact that getStaticPaths() is missing.

Screenshot of server error. SSG stands for Static-Site Generation

getStaticProps() utilizes the static-site generation concept. So Next.js will pre-render the respective page at build time. In the case of dynamic routes, however, Next.js doesn't know by itself which paths to pre-render. Instead, you have to step in and help – and this is where getStaticPaths() comes in handy.

So with getStaticPaths you can specify which paths of the dynamic routing should be pre-rendered and/or how unknown paths should be handled.

📋 Quick side note

If you are using getServerSideProps(), which can be used for similar reasons as getStaticProps(), you will notice that getStaticPaths() is actually not needed. Why is that?

getServerSideProps() doesn't use the static generation principle. Instead of building the page, Next.js pre-renders the page on each request with the returned data. This is called server-side rendering.

We don't have to tell Next.js which paths have to be statically pre-rendered while using getServerSideProps(), since there is no such thing for this function in the first place.

If you want to read more about this function, I can again recommend the official Next.js documentation for server-side rendering. However, this is out of the scope of this quick guide and I won't need getServerSideProps() for any of the following steps.

🔧 How to Setup Our Project

For this example, we will reproduce a small dynamic routing case. For this, I prepared a subfolder test in the pages folder. The pages folder gets automatically created by Next.js.

In the test folder, I insert the [something].tsx file ([something].js if you are using JavaScript and not TypeScript).

There is also a backendData folder at the root level of our Next.js application with the some-backend-data.json file (thus not in the pages folder). This file will provide us with the data which we will insert dynamically.

🔨 Setup for the backend JSON data

For this example, I'm creating some dummy data which will be embedded in the some-backend-data.json within the backendData folder. This way, we can reproduce a situation where you have access to some sort of data in the backend that you want to use on the frontend.

Here's what the some-backend-data.json file looks like:

{
    "stars": [
        { 
            "id": "St2-18", 
            "name": "Stephenson 2-18", 
            "description": "Stephenson 2-18 is a red supergiant (RSG) or possible extreme red hypergiant (RHG) star in the constellation of Scutum.", 
            "link": "https://en.wikipedia.org/wiki/Stephenson_2-18" 
        },
        { 
            "id": "UY-SC", 
            "name": "UY Scuti", 
            "description": "UY Scuti is an extreme red hypergiant or red supergiant star in the constellation Scutum.", 
            "link": "https://en.wikipedia.org/wiki/UY_Scuti"
        },
        { 
            "id": "RSGC1", 
            "name": "RSGC1-F01", 
            "description": "RSGC1-F01 is a red supergiant located in the RSGC1 open cluster in the constellation of Scutum.", 
            "link": "https://en.wikipedia.org/wiki/RSGC1-F01"
        }
    ]
}

In this file you will find some JSON formatted data. There is "stars" which is just an array with three objects. All three objects have the same format and include an id, a name, a description, and a link to an external web page.

As you may have figured out by now, these are actually some real stars in our universe.

In a real-world situation, you would probably have some sort of connection to a databank, but the actual data you are receiving from this databank could technically be formatted as in this example. So this is sufficient for our example setup.

🔑 Imports and interface

As a next step, we can dive into actually creating the Next.js [something].tsx dynamic route. Let's start with the required imports for this example:

import { GetStaticProps, GetStaticPaths  } from 'next';
import { useRouter } from 'next/router';
import path from 'path';
import fs from 'fs/promises';

interface starInterface {
    id: string
    name: string
    description: string
    link: string
}

Keep in mind that I'm using TypeScript here. If you are using JavaScript, that's of course fine as well. Just remember that you don't need the interface starInterface or import { GetStaticProps, GetStaticPaths } from 'next'.

💎 How to Create the Data Fetching Function

For the next step, I will prepare an async function called getData(), which will be helpful for the getStaticProps() and getStaticPaths() functions. This will look quite confusing, especially if you have never had contact with backend JavaScript code like you would expect in any Node.js application, for example.

Just bear with me for a few more seconds. You don't have to understand the following code in detail. We just need to know what the result of the getData() function is.

async function getData() {
    const filePath = path.join(process.cwd(), 'backendData', 'some-backend-data.json');
    const fileData = await fs.readFile(filePath);
    const data = JSON.parse(jsonData.toString());

    return data;
  }

As you can see, there are three variables: filePath, fileData, and data. With filePath we are just focusing on the file where we have our JSON data placed. So we are targeting the current working directory (cwd), then the backendData folder, and then the JSON file.

With fileData we are trying to read this file and extract the actual JSON data that is stored in it.

We need data to convert this fileData so we can actually use it for our next steps.

All in all, getData() basically just provides us with the data from the some-backend-data.json file so we can utilize it in getStaticProps() as well as in getStaticPaths(). There is not much more to it.

🔨 Setup for getStaticProps()

After we implement getData() (which will come in handy when we try to fetch our dummy backend data), we'll now create the getStaticProps() function next.

Here, we'll use getStaticProps() to enable pre-rendering for the specific fetched data for the paths in our dynamic route.

Before we jump right into the code example below, have a quick thought about what we actually want to accomplish.

The user should be directed to this specific dynamic route, which is indicated by a unique identifier in the URL. By that, I mean that we want /test/St2-18 and test/UY-SC to lead to the same dynamic page.

The data that the user will see there should, however, differ from each other since we want to fetch data for St2-18 and UY-SC, respectively.

We have a getData() function which helps reach out to our backend data. But we still have to know which exact data we want to extract from our dummy backend.

For this step, we can pull the specific identifier from the URL, St2-18 for example, and combine this with our extracted getData() result data.

From there we can search for the specific object containing the data we want to display within our backend's getData() result.

Now, let's head back to our code example to see this process in action.

See the following code section where we implement getStaticProps():

export const getStaticProps: GetStaticProps = async (context) => {
    const itemID = context.params?.something;
    const data = await getData();
    const foundItem = data.stars.find((item: starInterface) => itemID === item.id);

    if (!foundItem) {
      return {
        props: { hasError: true },
      }
  }

  return {
    props: {
      specificStarData: foundItem
    }
  }
}

For JavaScript, you can just omit GetStaticProps as the type for getStaticProps().

getStaticProps() can provide us with a context parameter through which we can reach some helpful methods. For now, it's just important to understand that through context we are able to access params and then afterwards reach out to the current identifier of our specific path for which something is the placerholder.

Remember that this file is actually called [something].tsx, which is why we access something in this context.

With this approach, we successfully extract the information we need from our URL to search for the specific object in our backend data array. Then we save this information in the itemID variable.

Let's say the user reaches out to /test/St2-18, then itemID would hold the value of St2-18.

Since we have our handy getData() function, we can just get our backend data through this function and save it to data.

Since we now have itemID as well as data, we can combine both variables and create foundItem. This returns the object that includes the itemID as an id.

With the if statement, we are checking if foundItem actually exists. Or in other words, we check if our backend data contains data with the corresponding id we extracted through our itemID.

If no data can be found, we return this boolean hasError with the value true. This helps us manage such cases on the frontend.

If there is data, then we return our foundItem to the frontend. Keep in mind that everything you return in this props object will actually be exposed to the frontend. So don't return any credentials (personal API keys, for example).

🔨 Setup for getStaticPaths()

Before we head to the frontend part of our dynamic page, we still need to implement the getStaticPaths() function:

  export const getStaticPaths: GetStaticPaths = async () => {
    const data = await getData();
    const pathsWithParams = data.stars.map((star: starInterface) => ({ params: { something: star.id }}))

    return {
        paths: pathsWithParams,
        fallback: true
    }
  }

For JavaScript, you can just omit GetStaticPaths as the type for getStaticPaths(). You can also delete starInterface for JavaScript.

Within the getStaticPaths() function, we want to tell Next.js which paths should be pre-rendered.

For this step, we are accessing our backend data with getData(), as you saw in getStaticProps().

getStaticPaths() demands a specific form for the paths within the return. You actually have two options:

• The first one is the approach I am using in this example: paths: [{ params: { something: star.id } }]. It should be an array with an object for every path you want Next.js to pre-render.
• The second option is to use path strings like this: paths: ['/test/St2-18', '...', '...'].

Both techniques achieve the same behavior, so just pick the one you prefer.

What is the fallback property?

It's important to understand is that you don't need to include every path which should be pre-rendered. This is especially helpful when you have a lot of cases to consider and don't want everything to be pre-rendered.

To handle such cases, the fallback property is particularly useful

You can read more about the fallback in detail in the official Next.js documentation.

In my own words, I would explain it like this:

• fallback set to false would automatically lead to a 404 error page whenever the user tried to access a path which wasn't recognized by getStaticPaths() through the paths property.
• fallback set to true doesn't automatically lead to a 404 error page whenever the user tries to access a path that doesn't exist in getStaticPaths(). This way, we still reach out to the frontend and are able to handle the situation there by displaying some sort of loading sequence, for example. You can also display an error on the frontend if there wasn't any data to be fetched when there was no valid item data for the specific path parameter.
• fallback set to 'blocking' doesn't automatically lead to a 404 error page whenever the user tries to access a path that doesn't exist in getStaticPaths(). It's similar to fallback set to true but now we basically omit any manual loading processes. Instead, the browser just takes a moment longer to fetch the data and then displays the page ready to go. This is helpful when you don't want to present a "Loading..." to the user, for example, and instead just let them wait a little longer before the page is loaded successfully. If no data could be found, then we still have the opportunity to create a manual error on the frontend.

Since we have such a small dataset, we are just giving every possible path to getStaticPaths(). So we technically don't need too much attention to the fallback property.

Still, I am setting fallback to true to show you how you can handle such manual errors as well as loading sequences that might occur.

📐 How to Configure the Frontend

In the last step, we'll configure our actual page. Anything in here will be the frontend content that the user will see:

function projectPage(props: { specificStarData: starInterface, 
hasError: boolean }) {
  const router = useRouter();

  if (props.hasError) {
    return <h1>Error - please try another parameter</h1>
  }

  if (router.isFallback) {
      return <h1>Loading...</h1>
  }

  return (
    <div>
      <h1>{props.specificStarData.name}</h1>
      <p>{props.specificStarData.description}</p>
      <a href={props.specificStarData.link}>More Information here (link)</a>
    </div>
  )
}

export default projectPage;

For JavaScript, you don't have to mention the starInterface as well as boolean within the function's arguments.

In the code above you can find our specificStarData as well as hasError, which both hold some values. Besides that, we utilize the useRouter() hook in order to have access to isFallback, which helps us handle any fallback cases.

Remember that the fallback from getStaticPaths() can be set to true or 'blocking' if you are not able to provide every dynamic route for pre-loading. In these cases, it would prevent your page from crashing.

Instead, it will load for some time on the fly as the user accesses this specific dynamic route and then provides the respective information.

For this potential loading sequence, we use router.isFallback in order to return JSX with some sort of loading indication for the user.

If there actually is an error because the user tried to access a dynamic path for which no data can be found, hasError steps in, indicating that there is an actual error.

Assuming that the user actually reached a dynamic path for which data could be fetched, the actual intended JSX output will be returned.

Following all the configuration steps (with fallback: true), we receive this output for the /test/St2-18 path:

Result for /test/St2-18

If we try to put in an invalid parameter, it first tries to load and then returns our manual set up error message:

Result for /test/this-will-produce-an-error

🎲 How to Test the fallback Property

And that's pretty much it! The result is a dynamic route which uses getStaticProps() as well as getStaticPaths() in order to pre-render the fetched data from our dummy backend.

When you are working with getStaticPaths() for the first time, I recommend trying out the different fallback values (true, false, 'blocking') to find out how exactly your application's behavior changes.

Since we are using fallback: true in our example, we are also able to just insert one possible path out of the three without having our application crash.

So let's say we change the paths property within getStaticPaths() to paths: ['/test/St2-18']. While we inserted all the paths before, we now just use one path with the string method I mentioned earlier instead of the { params: { something: star.id }} format.

With this configuration, you can still access /test/UY-SC, for example, but you'll notice that the Loading... message appears for a brief moment because we prepared this case in our if-statement with router.isFallback. After the data is loaded, it will successfully show up on the screen.

When using fallback: 'blocking' and paths: ['/test/St2-18'], you'll notice that you can't see any Loading.... Instead, the browser just takes a moment longer to load the data before changing the browser's content.

It's up to you which way you prefer.

✅ Conclusion

While this example shows the fundamental parts of getStaticProps() as well getStaticPaths(), there is still more to read about these Next.js functions.

Still, all you've read here is enough to get started working with getStaticProps() and getStaticPaths() on your own in a lot of cases.

📃 Resources & learning material

• Official Next.js documentation for Data Fetching.
• For learning more about Next.js on the whole, I can strongly recommend checking out the udemy course by Maximilian Schwarzmüller for Next.js. This course helped me a lot, at least.