Next 13 - Data fetching

I'm a full-stack developer from South Africa 🇿🇦. I love writing about JavaScript, HTML and CSS.
Search for a command to run...

I'm a full-stack developer from South Africa 🇿🇦. I love writing about JavaScript, HTML and CSS.
No comments yet. Be the first to comment.
Most of you know me for my consistency, a golden arrow in my blog series. I've written 1000 articles in 1008 days! Almost an article a day, and my honeymoon was the only holiday I ever took. I'm super proud of this achievement; it has been a fantasti...

It's not the first time I'll be talking about community. I think it's an essential aspect of any successful tool. This shows in my previous explorations of Astro, Medusa, and now Vendure as well. All these products thrive in a super open, welcoming, ...

The cool part about Vendure is how easy it is to set up and how abstract each layer is. Basically, we get the following elements: External database Server Worker Admin UI Frontend While this is amazing, it also brings a bit of complexity when it co...

The previous article looked at customizing Vendure on a data and process level. In this article, we'll look at customizing emails, as they are often a big part of a webshop system. We'll be looking at two different layers of customization for customi...

Even though Vendure is a pretty significant project out of the box, in some cases, we might want to go in and modify some elements to work to our specific use case. In this article, I'll take a high-level look at some elements we can customize within...

Data fetching is nothing new in Next, but they simplified how this works.
You might remember getServerSideProps and getStaticProps from the previous React versions. Those are no longer needed. In return, we get one uniform way of fetching data!
The recommended way of fetching data is using server components, as discussed in the previous article.
According to the docs, there are a lot of benefits from fetching from server components:
One important note is that they recommend you refetch data over passing it down. Underwater, they deduplicate your requests and return cached results. So it's more efficient to have the server do the heavy lifting, and the client requests the data.
They changed to use the fetch Web API, which is fantastic. It's a super powerful API, so happy to see this choice.
Fetch will always return a promise so we can await the result; by default, it's a cached request/results.
Let's show you an example.
In our component, we can create a data fetching function that would look like this.
async function getData() {
const res = await fetch('https://jsonplaceholder.typicode.com/todos');
return res.json();
}
Our component itself can then use this function like this.
export default async function AccountPage() {
const table = await getData();
return (
<ul>
{table.map((todo) => (
<li key={todo.id}>{todo.title}</li>
))}
</ul>
);
}
And yep, that's it, simple. I like the abstraction of thought here to simplify everything using native APIs.
It's also a great abstraction to move towards a unique concern architecture by simply making the components as small and self-sufficient as possible.
We also get many options around the fetch API that we can leverage, but it might be best to review them once we need them.
Thank you for reading my blog. Feel free to subscribe to my email newsletter and connect on Facebook or Twitter