Web Development

Rendering Storyblok images with Next.Js

20 January 2026

Like all CMS's Storyblok provides content editors with the facility to upload images to an asset library (or digital asset manager for a more current term). This asset library gives users the ability to organise all their assets into folders, assign tags, as well as more advanced tools like setting expiration dates and setting focal points.

For developers the asset library provides a CDN for serving images in way of AWS Cloudfront to minimise latency. There is also an image service with functionality to crop images as well as adjust the quality level and apply filters.

Rendering Images with Next.Js

To render images in Next.Js you should use Next's Image component. This extends the standard HTML <img> element to provide automatic optimisation.

1import Image from 'next/image'
2 
3export default function Page() {
4  return (
5    <Image
6      src="/profile.png"
7      width={500}
8      height={500}
9      alt="Picture of the author"
10    />
11  )
12}

The automatic optimisation will resize images to the desired height and width at a particular quality level.

As well as this the Image component offers other properties such as specifying responsive sizes.

Using next/image with Storyblok

To use the Next.js image component with Storyblok I create my own Image component that wraps next/image.

As you can see in the code below, this accepts properties for the StoryblokAsset as well as any other properties I might want to pass through such as className or the loading setting.

The component then extracts the filename from the StoryblokAsset to set the src property on the Next.Js Image component.

1import { StoryblokAsset } from "@/types/storyblok";
2import Image from "next/image";
3import React from "react";
4
5export interface ImageProps {
6  image: StoryblokAsset;
7  width?: number;
8  height?: number;
9  className?: string;
10  loading?: "lazy" | "eager";
11}
12
13export const ImageComponent: React.FC<ImageProps> = ({
14  image,
15  width,
16  height,
17  className,
18  loading = "lazy",
19}) => {
20  if (image.filename == null || image.filename.length === 0) {
21    console.error("Image filename is null");
22    return null;
23  }
24
25  return (
26    <Image
27      src={image.filename}
28      alt={image.alt || ""}
29      className={className}
30      width={width}
31      height={height}
32      loading={loading}
33    />
34  );
35};
36

However there's an improvement that could be made to this. Storyblok and Next.Js both provide the ability to optimise images and by directly using Next.Js's image component we will be using Next.Js over Storyblok.

This isn't a massive issue, but by using Next.Js the image request will now go through these steps:

The browser will request the Image from the website host (not Storyblok). e.g. Vercel or Netlify
The host will request the image from Storyblok's CDN
Storybloks CDN will return the full size image
The host will resize the image
The host will return the image to the browser

Not only is this extra steps than is really needed, it also means we're using bandwidth on the website host. So wouldn't it be better if the client could just directly load the image from Storyblok and have Storyblok resize it to begin with?

Next.Js Image Loaders

Next.Js provides a property on the Image component to specify a loader, which is a function to generate the image url. When a loader is set images will be set to use this URL rather than Next.Js's own url with the Next.Js image optimisation.

The loader can accept parameters for the original src, a width and quality level so that a URL can be constructed to a different image service. Note: Image loaders do not support a height parameter.

In the code below I have created a loader that will return the URL for Storybloks image service with the width and quality parameters being set.

1const storyblokLoader: ImageLoader = ({
2  src,
3  width,
4  quality,
5}: ImageLoaderProps): string => {
6  return `${src}/m/${width}x0/filters:quality(${quality || 75})`;
7};

The image loaders also work in conjunction with the sizes property meaning the correct responsive size urls will be populated using the loader.

The code for my complete ImageComponent is below.

1import { StoryblokAsset } from "@/types/storyblok";
2import Image, { ImageLoader, ImageLoaderProps } from "next/image";
3import React from "react";
4
5export interface ImageProps {
6  image: StoryblokAsset;
7  width?: number;
8  height?: number;
9  className?: string;
10  loading?: "lazy" | "eager";
11}
12
13function isStoryblokImage(src: string): boolean {
14  return src.includes("a.storyblok.com");
15}
16
17const storyblokLoader: ImageLoader = ({
18  src,
19  width,
20  quality,
21}: ImageLoaderProps): string => {
22  return `${src}/m/${width}x0/filters:quality(${quality || 75})`;
23};
24
25export const ImageComponent: React.FC<ImageProps> = ({
26  image,
27  width,
28  height,
29  className,
30  loading = "lazy",
31}) => {
32  if (image.filename == null || image.filename.length === 0) {
33    console.error("Image filename is null");
34    return null;
35  }
36
37  return (
38    <Image
39      loader={isStoryblokImage(image.filename) ? storyblokLoader : undefined}
40      src={image.filename}
41      alt={image.alt || ""}
42      className={className}
43      width={width}
44      height={height}
45      loading={loading}
46    />
47  );
48};
49

Creating Multiple Dynamic Routes with NextJs

15 August 2024

If you’ve used NextJs then you will probably be familiar with how it handles routing using the file system.

Files named page.tsx are organized into folders and the name of the folder becomes the name of the route. E.g. If the folder were named about-us then the route on the site will be /about-us. To create a page under another page, simply create a folder within a folder. E.g. company/about-us/page.tsx becomes /company/about-us.

Page names can also be dynamic, to do this you use a catch-all route which is defined with square brackets in the folder name. e.g. [slug]/page.tsx.

NextJs Routing Structure with dynamic route

Now all requests to the route of the site which don’t match a fixed path will be picked up by this page and will include a parameter matching the name within the square backets (in this example “slug”), which you can then use to render the page dynamically.

1export default function Page({ params }: { params: { slug: string } }) {
2  return <div>My Page Name: {params.slug}</div>
3}

Dynamic pages can also be nested. E.g. [category]/[product]/page.tsx. In this example a request to /electronics/50-inch-tv will route to the page including the parameters category=electronics, and product=50-inch-tv.

By using triple dots in-front of the parameter name NextJs will catch all requests to subpages and provide the hierarchy as an array to the parameter. E.g. […slug]/page.tsx will capture requests to /company/about-us and have a parameter named slug with the values [‘company’, ‘about-us’].

This is all explained on the NextJs site in detail https://nextjs.org/docs/app/building-your-application/routing/dynamic-routes#catch-all-segments

However, the one thing you can’t do is have two or more dynamic paths at the same level. E.g. Creating…

/[category]/page.tsx

/[slug]/page.tsx

Will lead to an error saying "Error: You cannot use different slug names for the same dynamic path".

The official way to have more than one dynamic path is to separate them by placing one into a subfolder, so in my scenario I could have…

/products/[category]/page.tsx

/[slug]/page.tsx

Now any routes starting /products/ will be routed to the category page rather than the slug page. However this typically doesn’t match the requirement and hasn’t been needed for the majority of sites being built with a CMS.

Creating multiple dynamic paths in NextJs using one catch all page

The first option for enabling multiple dynamic paths at the same level is to have one catch-all routes and within that file figure out what the page should be. E.g. /[…slug]/page.tsx

Now all requests to the site will be captured by this route and within the page you can write custom logic to determine if the first value is a category or generic page.

To keep code clean the actual rendering of the different page types can be split into separate components with page.tsx handling the logic for which to include.

This setup works well, however it has a tradeoff that a lot of functionality provided by NextJs through it’s folder structure is lost. E.g. NextJs support layout files at different levels of the file system but here you would be restricted to just the one.

Creating multiple dynamic paths in NextJs using rewrites

An alternative method is to structure the dynamic pages into separate subfolders as per the official way and then hide this using Rewrites.

What is a Rewrite?

A rewrite is like a redirect, but one that happens server side and is therefore invisible to the user. When a request goes into the server it is first checked against the rewrite rules and if it matches one, the request is rewritten to that URL rather than being passed as it to the application.

Anyone old enough to remember programming in Classic ASP may remember this being one of the methods first used to implement friendly URLs rather than having query strings for everything dynamic.

How to setup a rewrite in NextJs

Rewrites are configured in the next.config.mjs file.

1module.exports = {
2  async rewrites() {
3    return {
4      beforeFiles: [
5        {
6          source: '/electronics/:slug*',
7          destination: '/products/electronics/:slug*',
8        },
9      ]
10    },
11  },
12}

In this example I am creating a re-write for anything going to a path starting /electronics/ to route the request to the path /products/electronics/

Hardcoding the list of categories as re-writes isn’t much better than creating a lot of hard coded sub-folders, but this is easily fixed by dynamically writing the list which will happen when the site is built.

Creating a redirect in NextJs

The solution now works, however any requests to the /products/ url will also resolve as duplicate pages. To overcomes this we can create a standard redirect to put people back on our preferred path.

1module.exports = {
2  async redirects() {
3    return [
4      {
5        source: '/products/electronics/:slug*',
6        destination: '/electronics/:slug*',
7        permanent: true,
8      },
9    ]
10  },
11}

One thing to be aware of

While this is a solution that will work, one thing to note is that there may be a limit to how far it will scale. If you hit the point of creating over 1000 redirects or rewrites the NextJs build script will start warning of potential performance hits from there being to many redirects.

This isn’t something I’ve experienced, but each rewrite is effectively another check that needs to be performed against each request.

Allowing CORS on Localhost

24 June 2024

Imagine the scenario your developing an API in .NET 6 and a front end in React. Locally you'd like to run both your API and front end and have the front end call the API. That's when you discover the CORS issue.

What is CORS?

CORS stands for cross-origin resource sharing. It's one of the browser's protections against malicious activity that checks with a server if the domain a request is originating from should actually be able to call HTTP endpoints on the provider.

The server (that's your API) will return if a domain is permitted to make a request to a given endpoint or not. If it's not you'll see a CORS error in the browsers network tab.

When your API and front-end code are running on the same domain this isn't an issue because there's no cross-origin to deal with. However, locally your front-end and backend api are likely on different localhost ports.

How to update ASP.NET CORS settings

In your program.cs file where builder.Build() and app.Run() are being called we need to add some extra logic.

1// Program.cs
2// A string to name the policy
3string MyAllowSpecificOrigins = "_myAllowSpecificOrigins";
4
5var builder = WebApplication.CreateBuilder(args);
6
7// Add the cors policy
8builder.Services.AddCors(o => o.AddPolicy(
9    MyAllowSpecificOrigins, builder =>
10    {
11        builder.WithOrigins("http://localhost:3000") //Update with correct port number of front-end
12        .AllowAnyHeader()
13        .AllowAnyMethod();
14    }));
15
16// There likely a lot of code between this bit and the next line
17
18var app = builder.Build();
19// Other code omited 
20
21// Tell the APP to use CORS
22app.UseCors(MyAllowSpecificOrigins);
23app.Run();

To avoid this having any effect on production you can also wrap is in an environment check.

1if (app.Environment.IsDevelopment())
2{
3    app.UseCors(MyAllowSpecificOrigins);
4}

Debugging NextJS 14 with VSCode

8 May 2024

Using debugging tools when you're developing is something that in my mind is absolutely essential, and I'm shocked whenever I see people response.writing out values to work out what's going wrong in there application. In the past I've written about debugging VueJS in VS Code and the setup for NextJs is somewhat similar.

With VS Code you have launch.json file which instructs how VS Code should start an application in debug mode when you hit F5.

Launch.json for NextJs 14 using app router

The launch.json file for NextJs 14 is very simple and consists of the following:

1{
2  "version": "0.2.0",
3  "configurations": [
4    {
5      "name": "Next.js: debug full stack",
6      "type": "node-terminal",
7      "request": "launch",
8      "command": "npm run dev",
9      "serverReadyAction": {
10        "pattern": "- Local:.+(https?://.+)",
11        "uriFormat": "%s",
12        "action": "debugWithChrome"
13      }
14    }
15  ]
16}
17

Launch.json for NextJs 13 using page router

The launch.json file for NextJs13 is slightly different. This one also includes an attach option which will attach to the running process if you've already manually started NextJs from the command line.

1{
2  "version": "0.2.0",
3  "configurations": [
4    {
5      "name": "Next.js: debug full stack",
6      "type": "node-terminal",
7      "request": "launch",
8      "command": "npm run dev",
9      "console": "integratedTerminal",
10      "serverReadyAction": {
11        "pattern": "started server on .+, url: (https?://.+)",
12        "uriFormat": "%s",
13        "action": "debugWithChrome"
14      }
15    }
16  ]
17}
18

This file will also work for NextJs 14, however I found that any component marked as "use client" doesn't hit any of the breakpoints in client side code. It also doesn't trigger chrome to open when the application starts.