{data.data.attributes.title}

{data.data.attributes.description}

Key Points:

• Create a Newsletter Signup collection type in Strapi
• Set up API permissions for form submissions
• Implement Server Actions in Next.js 15 for form handling
• Add form validation using Zod
• Create proper error handling for form submissions
• Implement success and error messaging for users

// POST request to http://localhost:1337/api/newsletter-signups
{
  "data": {
    "email": "test@example.com"
  }
}

yarn add zod

// In data/actions.ts
"use server";

import { z } from "zod";
import { subscribeService } from "./services";

// Initial state for the form
const initialState = {
  zodErrors: null,
  strapiErrors: null,
  errorMessage: null,
  successMessage: null,
};

// Form validation schema
const subscribeSchema = z.object({
  email: z.string().email("Please enter a valid email address"),
});

export async function subscribeAction(prevState, formData) {
  // Get the email from the form
  const email = formData.get("email");

  // Validate the email
  const validatedFields = subscribeSchema.safeParse({ email });

  // If validation fails, return errors
  if (!validatedFields.success) {
    return {
      ...prevState,
      zodErrors: validatedFields.error.flatten().fieldErrors,
      errorMessage: "Invalid input",
      successMessage: null,
    };
  }

  // Prepare data for Strapi
  const dataToSend = {
    data: {
      email: validatedFields.data.email,
    },
  };

  // Send data to Strapi
  const responseData = await subscribeService(dataToSend);

  // If no response, return server error
  if (!responseData) {
    return {
      ...prevState,
      zodErrors: null,
      strapiErrors: null,
      errorMessage: "Oops, something went wrong. Please try again later.",
      successMessage: null,
    };
  }

  // If Strapi returns an error
  if (responseData.error) {
    return {
      ...prevState,
      zodErrors: null,
      strapiErrors: responseData.error,
      errorMessage: "Failed to subscribe",
      successMessage: null,
    };
  }

  // Success case
  return {
    ...prevState,
    zodErrors: null,
    strapiErrors: null,
    errorMessage: null,
    successMessage: "Successfully subscribed!",
  };
}

// In data/services.ts
import { fetchAPI } from "@/utils/fetchApi";

interface SubscribeData {
  data: {
    email: string;
  };
}

export async function subscribeService(data: SubscribeData) {
  try {
    const response = await fetchAPI("/api/newsletter-signups", {
      method: "POST",
      body: JSON.stringify(data),
    });

    return response;
  } catch (error) {
    console.error("Error in subscribe service:", error);
    return null;
  }
}

// In components/blocks/Subscribe.tsx
"use client";

import { useActionState } from "react-dom";
import { subscribeAction } from "@/data/actions";

// Initial state
const initialState = {
  zodErrors: null,
  strapiErrors: null,
  errorMessage: null,
  successMessage: null,
};

export default function Subscribe({
  headline,
  content,
  placeholderText,
  buttonText,
}) {
  // Use the action state to get form state and action
  const [formState, formAction] = useActionState(subscribeAction, initialState);

  // Get errors from form state
  const zodErrors = formState.zodErrors;
  const strapiErrors = formState.strapiErrors;
  const errorMessage = formState.errorMessage || 
                       zodErrors?.email?.[0] ||
                       strapiErrors?.message;
  const successMessage = formState.successMessage;

  return (

); }

// In components/SubmitButton.tsx
"use client";

import { useFormStatus } from "react-dom";

export default function SubmitButton({ children }) {
  const { pending } = useFormStatus();
  
  return (
    
      {pending ? "Loading..." : children}
    
  );
}

My Take:

Server Actions in Next.js 15 are a game-changer for handling forms. They provide a clean way to implement form submissions without having to create separate API routes. Combining Server Actions with Zod for validation creates a robust system for handling user input. The approach of using useActionState to manage form state provides a great developer experience while maintaining the benefits of server-side validation.

Key Points:

• Create an Article collection type with dynamic content blocks
• Build components for different content types (headings, paragraphs, images)
• Set up dynamic routes for article pages
• Generate a table of contents from headings
• Display related articles at the bottom of the page
• Add proper navigation and metadata

// In components/blocks/Heading.tsx
export default function Heading({ heading, linkId }) {
  return (

); }

// In components/blocks/Paragraph.tsx
import ReactMarkdown from 'react-markdown';

export default function Paragraph({ content }) {
  return (

); }

// In components/blocks/FullImage.tsx
import StrappyImage from '../StrappyImage';

export default function FullImage({ image }) {
  return (

); }

// In components/blocks/ParagraphWithImage.tsx
import ReactMarkdown from 'react-markdown';
import StrappyImage from '../StrappyImage';

export default function ParagraphWithImage({
  content,
  image,
  reversed,
  imageLandscape,
}) {
  return (

); }

// In components/BlockRenderer.tsx
// Update the switch statement to include new components
switch (block.__component) {
  case 'blocks.hero-section':
    return ;
  case 'blocks.info-block':
    return ;
  case 'blocks.featured-article':
    return ;
  case 'blocks.subscribe':
    return ;
  case 'blocks.heading':
    return ;
  case 'blocks.paragraph':
    return ;
  case 'blocks.full-image':
    return ;
  case 'blocks.paragraph-with-image':
    return ;
  default:
    console.warn(`Unknown block type: ${block.__component}`);
    return null;
}

// In data/loaders.ts
export async function getContentBySlug(type, slug) {
  const query = qs.stringify({
    filters: {
      slug: {
        $eq: slug,
      },
    },
    populate: {
      image: {
        fields: ['url', 'alternativeText'],
      },
      blocks: {
        on: {
          'blocks.heading': {
            populate: '*',
          },
          'blocks.paragraph': {
            populate: '*',
          },
          'blocks.full-image': {
            populate: {
              image: {
                fields: ['url', 'alternativeText'],
              },
            },
          },
          'blocks.paragraph-with-image': {
            populate: {
              image: {
                fields: ['url', 'alternativeText'],
              },
            },
          },
          'blocks.hero-section': {
            populate: {
              image: {
                fields: ['url', 'alternativeText'],
              },
              logo: {
                populate: {
                  image: {
                    fields: ['url', 'alternativeText'],
                  },
                },
              },
              cta: {
                populate: '*',
              },
            },
          },
        },
      },
    },
  });

  try {
    const url = `/api/${type}?${query}`;
    const data = await fetchAPI(url);
    
    if (data.data.length === 0) {
      return null;
    }
    
    return {
      article: data.data[0].attributes,
      blocks: data.data[0].attributes.blocks,
    };
  } catch (error) {
    console.error(`Error fetching content with slug ${slug}:`, error);
    return null;
  }
}

// In app/blog/[slug]/page.tsx
import { getContentBySlug } from '@/data/loaders';
import { notFound } from 'next/navigation';
import HeroSection from '@/components/blocks/HeroSection';
import ArticleOverview from '@/components/ArticleOverview';
import BlockRenderer from '@/components/BlockRenderer';
import ContentList from '@/components/ContentList';
import Card from '@/components/Card';

interface PageProps {
  params: {
    slug: string;
  };
}

export default async function SingleBlogRoute({ params }: PageProps) {
  const { slug } = params;
  const data = await getContentBySlug('articles', slug);
  
  if (!data) {
    notFound();
  }
  
  const { article, blocks } = data;
  
  // Generate table of contents from heading blocks
  const tableOfContents = blocks
    .filter(block => block.__component === 'blocks.heading')
    .map(block => ({
      heading: block.heading,
      linkId: block.linkId
    }));
  
  // Component for displaying blog cards
  const BlogCard = (props) => (
    
  );
  
  return (

  );
}

// In components/ArticleOverview.tsx
import Link from 'next/link';

interface TableOfContentItem {
  heading: string;
  linkId: string;
}

interface ArticleOverviewProps {
  description: string;
  tableOfContents?: TableOfContentItem[];
}

export default function ArticleOverview({
  description,
  tableOfContents = [],
}: ArticleOverviewProps) {
  return (

); }

My Take:

The approach to creating dynamic blog content is incredibly powerful. By using a combination of different content blocks that can be arranged in any order, content editors have complete flexibility in how they structure their articles. The table of contents generation from heading blocks is a nice touch that improves user experience. This pattern could be extended to support more complex content types like code blocks, quotes, or embedded media.

Key Points:

• Create a Search component with debounced input
• Implement pagination for content lists
• Use URL parameters to store search and pagination state
• Update Strapi queries to handle filtering and pagination
• Create reusable components that can be applied to different content types
• Make search results and pagination state shareable via URLs

yarn add use-debounce

// In components/Search.tsx
"use client";

import { useSearchParams, usePathname, useRouter } from "next/navigation";
import { useDebounceCallback } from "use-debounce";

export default function Search() {
  const searchParams = useSearchParams();
  const pathname = usePathname();
  const { replace } = useRouter();
  
  // Handle search with debounce to avoid too many updates
  const handleSearch = useDebounceCallback((term) => {
    const params = new URLSearchParams(searchParams);
    
    // Reset to page 1 when search changes
    params.set("page", "1");
    
    if (term) {
      params.set("query", term);
    } else {
      params.delete("query");
    }
    
    // Update URL with search parameters
    replace(`${pathname}?${params.toString()}`);
  }, 300);
  
  return (

); }

// In components/Pagination.tsx
"use client";

import { useSearchParams, usePathname, useRouter } from "next/navigation";

interface PaginationProps {
  pageCount: number;
}

export default function Pagination({ pageCount }: PaginationProps) {
  const searchParams = useSearchParams();
  const pathname = usePathname();
  const { replace } = useRouter();
  
  // Get current page from URL or default to 1
  const currentPage = Number(searchParams.get("page") || "1");
  
  // Create URL for a specific page
  const createPageURL = (pageNumber: number) => {
    const params = new URLSearchParams(searchParams);
    params.set("page", pageNumber.toString());
    return `${pathname}?${params.toString()}`;
  };
  
  return (

); }

// In data/loaders.ts
const BASE_PAGE_SIZE = 3;

export async function getContent(
  path: string,
  featured?: boolean,
  query?: string,
  page?: string
) {
  // Set up filters
  const filters: any = {};
  
  // Add featured filter if provided
  if (featured) {
    filters.featured = {
      $eq: true,
    };
  }
  
  // Add search query filter if provided
  if (query) {
    filters.$or = [
      {
        title: {
          $containsi: query,
        },
      },
      {
        description: {
          $containsi: query,
        },
      },
    ];
  }
  
  // Create query with filters, pagination, and population
  const contentQuery = qs.stringify({
    filters,
    pagination: {
      pageSize: BASE_PAGE_SIZE,
      page: page ? parseInt(page) : 1,
    },
    populate: {
      image: {
        fields: ['url', 'alternativeText'],
      },
    },
    sort: ['createdAt:desc'],
  });
  
  try {
    const url = `/api/${path}?${contentQuery}`;
    const data = await fetchAPI(url);
    
    return {
      data: data.data,
      meta: data.meta,
    };
  } catch (error) {
    console.error(`Error fetching content from ${path}:`, error);
    return {
      data: [],
      meta: {
        pagination: {
          pageCount: 0,
        },
      },
    };
  }
}

// In components/ContentList.tsx
import { getContent } from '@/data/loaders';
import Search from './Search';
import Pagination from './Pagination';

interface ContentListProps {
  headline: string;
  path: string;
  component: React.ComponentType;
  featured?: boolean;
  showSearch?: boolean;
  showPagination?: boolean;
  query?: string;
  page?: string;
  headlineAlignment?: 'left' | 'center' | 'right';
}

export default async function ContentList({
  headline,
  path,
  component: Component,
  featured = false,
  showSearch = false,
  showPagination = false,
  query = "",
  page = "1",
  headlineAlignment = 'left',
}: ContentListProps) {
  // Fetch content with filters and pagination
  const { data: articles, meta } = await getContent(path, featured, query, page);
  const pageCount = meta.pagination.pageCount || 1;
  
  return (

); }

// In app/blog/page.tsx
interface BlogPageProps {
  searchParams: {
    query?: string;
    page?: string;
  };
}

export default async function BlogPage({ searchParams }: BlogPageProps) {
  const { query, page } = searchParams;
  
  // Create blog card component
  const BlogCard = (props) => (
    
  );
  
  return (

); }

My Take:

The approach of storing search and pagination state in URL parameters has several advantages. It makes the current state shareable, bookmarkable, and preservable across page refreshes. The use of debounced search prevents unnecessary API calls while typing, improving performance. This pattern could be extended to include more advanced filtering options like categories, tags, or date ranges.

Key Points:

• Create an Event collection type in Strapi
• Set up fields for event details (title, description, date, price)
• Reuse the content list pattern for displaying events
• Create an events page with search and filtering
• Implement dynamic routes for individual event pages
• Add proper formatting for dates and prices

// In app/events/page.tsx
import { getContentBySlug, getContent } from '@/data/loaders';
import { notFound } from 'next/navigation';
import BlockRenderer from '@/components/BlockRenderer';
import ContentList from '@/components/ContentList';
import EventSignupForm from '@/components/EventSignupForm';
import Card from '@/components/Card';

interface EventsPageProps {
  searchParams: {
    query?: string;
    page?: string;
  };
}

export default async function EventsPage({ searchParams }: EventsPageProps) {
  const { query, page } = searchParams;
  
  // Get the "Stay in touch" event for the main form
  const stayInTouchData = await getContentBySlug('events', 'stay-in-touch');
  
  if (!stayInTouchData) {
    notFound();
  }
  
  const { article: event, blocks } = stayInTouchData;
  
  // Create event card component
  const EventCard = (props) => (
    
  );
  
  return (

); }

// This extends the Card component with event-specific styling
import { formatDate } from '@/utils/formatDate';

export default function EventCard({ 
  title, 
  description, 
  slug, 
  image, 
  price,
  startDate,
  basePath,
}) {
  return (

); }

// In utils/formatDate.ts
export function formatDate(dateString: string): string {
  const date = new Date(dateString);
  
  return new Intl.DateTimeFormat('en-US', {
    weekday: 'long',
    year: 'numeric',
    month: 'long',
    day: 'numeric',
    hour: 'numeric',
    minute: 'numeric',
  }).format(date);
}

// In components/EventSignupForm.tsx
import BlockRenderer from './BlockRenderer';

export default function EventSignupForm({ event, blocks }) {
  return (

); }

My Take:

The approach of reusing the ContentList pattern for events demonstrates the power of creating generic, reusable components. By simply swapping out the component prop, you can display different types of content with the same pagination and search functionality. This pattern makes your codebase more maintainable and reduces duplication. The separation of the “Stay in touch” event as a special case is a clever way to handle the general contact form while still using the same data structure.

Key Points:

• Create an EventSignup collection type in Strapi
• Set up a relation between EventSignup and Event
• Implement a form interface for collecting user information
• Create reusable form components (TextInput, SubmitButton)
• Set up the server action for form submission
• Add proper error handling and success messaging

// In components/TextInput.tsx
interface TextInputProps {
  label: string;
  name: string;
  type?: 'text' | 'email' | 'tel';
  placeholder?: string;
  required?: boolean;
  errors?: string[];
  defaultValue?: string;
}

export default function TextInput({
  label,
  name,
  type = 'text',
  placeholder,
  required = true,
  errors,
  defaultValue = '',
}: TextInputProps) {
  return (

); }

// In components/EventSignupForm.tsx
"use client";

import { useActionState } from "react-dom";
import BlockRenderer from './BlockRenderer';
import TextInput from './TextInput';
import SubmitButton from './SubmitButton';
import { eventSubscribeAction } from '@/data/actions';

// Initial state for the form
const initialState = {
  zodErrors: null,
  strapiErrors: null,
  errorMessage: null,
  successMessage: null,
  formData: {
    firstName: '',
    lastName: '',
    email: '',
    telephone: '',
  },
};

export default function EventSignupForm({ event, blocks }) {
  const [formState, formAction] = useActionState(eventSubscribeAction, initialState);
  
  // Get errors and success message from form state
  const zodErrors = formState.zodErrors;
  const strapiErrors = formState.strapiErrors;
  const errorMessage = formState.errorMessage;
  const successMessage = formState.successMessage;
  
  return (

); }

My Take:

Creating reusable form components like TextInput makes it much easier to maintain consistency across your application. The pattern of passing error messages as props allows for flexible error display while keeping the core input component simple. The approach of storing form data in the form state ensures that users don’t lose their input if validation fails, which significantly improves the user experience.

Key Points:

• Implement server-side validation using Zod
• Create validation schemas for form fields
• Add phone number validation with regex
• Handle Strapi-specific errors
• Display appropriate error messages to users
• Implement success messages for completed submissions

// In data/actions.ts
"use server";

import { z } from "zod";
import { eventSubscribeService } from "./services";

// Initial state for the form
const initialState = {
  zodErrors: null,
  strapiErrors: null,
  errorMessage: null,
  successMessage: null,
  formData: {
    firstName: '',
    lastName: '',
    email: '',
    telephone: '',
  },
};

// Form validation schema
const eventSubscribeSchema = z.object({
  firstName: z.string().min(1, "First name is required"),
  lastName: z.string().min(1, "Last name is required"),
  email: z.string().email("Please enter a valid email address"),
  telephone: z.string()
    .min(1, "Phone number is required")
    .refine(
      (val) => /^(+d{1,3})?s?(?d{3})?[s.-]?d{3}[s.-]?d{4}$/.test(val),
      "Please enter a valid phone number"
    ),
  eventId: z.string(),
});

export async function eventSubscribeAction(prevState, formData) {
  // Extract form data
  const formValues = {
    firstName: formData.get("firstName"),
    lastName: formData.get("lastName"),
    email: formData.get("email"),
    telephone: formData.get("telephone"),
    eventId: formData.get("eventId"),
  };

  // Validate form data
  const validatedFields = eventSubscribeSchema.safeParse(formValues);

  // If validation fails, return errors
  if (!validatedFields.success) {
    return {
      ...prevState,
      zodErrors: validatedFields.error.flatten().fieldErrors,
      strapiErrors: null,
      errorMessage: "Please correct the errors in the form",
      successMessage: null,
      formData: formValues,
    };
  }

  // Prepare data for Strapi
  const dataToSend = {
    data: {
      firstName: validatedFields.data.firstName,
      lastName: validatedFields.data.lastName,
      email: validatedFields.data.email,
      telephone: validatedFields.data.telephone,
      event: validatedFields.data.eventId,
    },
  };

  // Send data to Strapi
  const responseData = await eventSubscribeService(dataToSend);

  // If no response, return server error
  if (!responseData) {
    return {
      ...prevState,
      zodErrors: null,
      strapiErrors: null,
      errorMessage: "Oops, something went wrong. Please try again later.",
      successMessage: null,
      formData: formValues,
    };
  }

  // If Strapi returns an error
  if (responseData.error) {
    return {
      ...prevState,
      zodErrors: null,
      strapiErrors: responseData.error,
      errorMessage: "Failed to subscribe",
      successMessage: null,
      formData: formValues,
    };
  }

  // Success case
  return {
    ...prevState,
    zodErrors: null,
    strapiErrors: null,
    errorMessage: null,
    successMessage: "Successfully subscribed!",
    formData: {
      firstName: '',
      lastName: '',
      email: '',
      telephone: '',
    },
  };
}

// In data/services.ts
// Add a new service for event signup
interface EventSubscribeData {
  data: {
    firstName: string;
    lastName: string;
    email: string;
    telephone: string;
    event: string; // ID of the event
  };
}

export async function eventSubscribeService(data: EventSubscribeData) {
  try {
    const response = await fetchAPI("/api/event-signups", {
      method: "POST",
      body: JSON.stringify(data),
    });

    return response;
  } catch (error) {
    console.error("Error in event subscribe service:", error);
    return null;
  }
}

My Take:

Server-side validation with Zod provides a robust way to ensure data integrity before it reaches your database. The approach of returning detailed error information to the client allows for clear user feedback without exposing sensitive information. The telephone validation using regex is particularly useful, as phone number formats can vary widely. In a production application, you might want to add additional validation for security, such as CSRF protection or rate limiting.

Key Points:

• Set up dynamic routing for event detail pages
• Create a page component for displaying event details
• Reuse the EventSignupForm component
• Display related events at the bottom of the page
• Add proper navigation and metadata
• Handle 404 errors for non-existent events

// In app/events/[slug]/page.tsx
import { getContentBySlug } from '@/data/loaders';
import { notFound } from 'next/navigation';
import EventSignupForm from '@/components/EventSignupForm';
import ContentList from '@/components/ContentList';
import Card from '@/components/Card';

interface EventPageProps {
  params: {
    slug: string;
  };
}

export default async function EventPage({ params }: EventPageProps) {
  const { slug } = params;
  const data = await getContentBySlug('events', slug);
  
  if (!data) {
    notFound();
  }
  
  const { article: event, blocks } = data;
  
  // Create event card component
  const EventCard = (props) => (
    
  );
  
  return (

  );
}

// In components/Card.tsx
// Updated to add navigation links for events
import Link from 'next/link';
import StrappyImage from './StrappyImage';
import { formatDate } from '@/utils/formatDate';

export default function Card({ 
  title, 
  description, 
  slug, 
  image, 
  price,
  startDate,
  basePath,
}) {
  return (

); }

My Take:

The reuse of components across different pages demonstrates the power of component-based architecture. By creating flexible, reusable components like EventSignupForm and ContentList, you can build complex pages with minimal code duplication. The approach of displaying related events on the detail page is a nice touch that encourages users to explore more content and potentially sign up for multiple events.

Key Points:

• Review the complete project structure and components
• Discuss potential improvements and extensions
• Add metadata and SEO optimization
• Consider performance optimizations
• Explore deployment options for Next.js and Strapi
• Reflect on the strengths of this tech stack for freelancers

// In app/layout.tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  title: {
    template: '%s | Surf Camp',
    default: 'Surf Camp - Summer Adventures',
  },
  description: 'Join our summer surf camp for an unforgettable adventure!',
  keywords: ['surf camp', 'summer camp', 'adventures', 'surfing lessons'],
};

// In app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const { slug } = params;
  const data = await getContentBySlug('articles', slug);
  
  if (!data) {
    return {
      title: 'Article Not Found',
      description: 'The requested article could not be found.',
    };
  }
  
  const { article } = data;
  
  return {
    title: article.title,
    description: article.description,
    openGraph: {
      title: article.title,
      description: article.description,
      images: [
        {
          url: getStrapiMedia(article.image.url),
          width: article.image.width,
          height: article.image.height,
          alt: article.image.alternativeText || article.title,
        },
      ],
    },
  };
}

My Take:

The combination of Next.js 15 and Strapi 5 creates a powerful, flexible stack for building modern websites. The server components in Next.js 15 provide excellent performance while maintaining a great developer experience. Strapi’s headless CMS capabilities make it easy for clients to manage their content without developer intervention. This stack is particularly well-suited for freelancers and agencies who need to deliver high-quality websites with content management capabilities on tight timelines.

Key Points:

• Next.js 15 provides server components, improved performance, and an intuitive routing system
• Strapi 5 offers a flexible, customizable headless CMS where clients can manage content
• The decoupled architecture allows for future front-end changes without affecting content
• This stack is ideal for freelancers and agencies building small to medium business websites
• The tutorial includes a complete Figma design file that guides the development process

My Take:

This tech stack strikes an excellent balance between developer needs and client usability. The separation of concerns between front-end and back-end makes this approach particularly future-proof—if you ever need to rebuild the front-end with a different technology, your content remains accessible through Strapi’s API.

Key Points:

• Create two separate folders for client (Next.js) and server (Strapi)
• Configure Next.js 15 with App Router and without Tailwind (using SASS instead)
• Set up Strapi 5 with SQLite database for simplicity
• Create a Git repository for version control of the entire project
• Set up a resources folder for code snippets and documentation

# Install Next.js
npx create-next-app@latest client
# Answer the setup questions:
# ✅ Would you like to use TypeScript? Yes
# ✅ Would you like to use ESLint? Yes
# ❌ Would you like to use Tailwind CSS? No
# ✅ Would you like to use the src/ directory? Yes
# ✅ Would you like to use App Router? Yes
# ❌ Would you like to customize the default import alias? No

# Install Strapi
npx create-strapi-app@latest server
# Answer the setup questions:
# Choose your installation type: Custom (manual settings)
# Choose your preferred database client: SQLite
# Database name: default
# Host: 127.0.0.1
# Port: 1337
# Username: admin
# Password: [your-secure-password]
# Enable SSL connection: No

My Take:

Using a monorepo approach (keeping both frontend and backend in one repository) makes deployment and version control much simpler. For real-world projects, you might consider using a more robust database like PostgreSQL instead of SQLite, especially if you’re planning to deploy to a platform like Heroku or Digital Ocean.

Key Points:

• Understand the difference between Single Types and Collection Types in Strapi
• Create a “Homepage” Single Type with title and description fields
• Configure permissions in Strapi’s users & permissions plugin
• Test API endpoints using Postman or the browser
• Create a data fetching utility in Next.js to consume Strapi’s API
• Implement basic error handling for API requests

// In your Next.js application
// Create utils/fetchApi.ts for API requests
export async function fetchAPI(
  path: string,
  options = {}
) {
  try {
    const defaultOptions = {
      headers: {
        'Content-Type': 'application/json',
      },
    };

    const mergedOptions = {
      ...defaultOptions,
      ...options,
    };

    const res = await fetch(`${getStrapiURL()}${path}`, mergedOptions);
    const data = await res.json();

    return data;
  } catch (error) {
    console.error(error);
    throw new Error(`Failed to fetch data from API: ${error.message}`);
  }
}

// Create utils/getStrapiURL.ts
export function getStrapiURL() {
  return process.env.NEXT_PUBLIC_STRAPI_API_URL || 'http://localhost:1337';
}

// Create data/loaders.ts for data fetching
export async function getHomepageData() {
  try {
    const homepage = await fetchAPI('/api/homepage');
    return homepage;
  } catch (error) {
    console.error('Error fetching homepage data:', error);
    return null;
  }
}

// In app/page.tsx
import { getHomepageData } from '@/data/loaders';
import { notFound } from 'next/navigation';

export default async function HomeRoute() {
  const data = await getHomepageData();
  
  if (!data) {
    notFound();
  }
  
  return (

); }

My Take:

The way Strapi structures its API responses with nested data.attributes can be a bit confusing at first. Creating utility functions to abstract away these details makes your code more readable and maintainable. For larger projects, you might want to add TypeScript interfaces to define the expected data structure from each API endpoint.

Key Points:

• Install SASS in your Next.js project using yarn add sass
• Create a structured approach to organizing your styles
• Import your main stylesheet in the root layout
• Understand BEM (Block Element Modifier) methodology for CSS naming
• Set up component-specific SASS files

src/
└── sass/
    ├── main.scss               # Main entry point that imports all other files
    ├── base/
    │   ├── _reset.scss         # CSS reset
    │   ├── _typography.scss    # Typography styles
    │   └── _variables.scss     # Variables for colors, spacing, etc.
    ├── components/
    │   ├── _hero.scss          # Styles for hero section
    │   ├── _info-block.scss    # Styles for info blocks
    │   └── _button.scss        # Styles for buttons
    ├── layout/
    │   ├── _header.scss        # Styles for header
    │   ├── _footer.scss        # Styles for footer
    │   └── _container.scss     # Styles for container
    └── utilities/
        ├── _mixins.scss        # SASS mixins
        └── _helpers.scss       # Helper classes

// In app/layout.tsx
import '@/src/sass/main.scss';

export default function RootLayout({ children }) {
  return (
    
      {children}
    
  );
}

// Example of BEM methodology in SASS
.hero {
  position: relative;
  width: 100%;
  min-height: 80vh;
  
  &__title {
    font-size: 3rem;
    font-weight: bold;
    margin-bottom: 1rem;
  }
  
  &__subtitle {
    font-size: 1.5rem;
    margin-bottom: 2rem;
  }
  
  &__cta {
    display: inline-block;
    padding: 1rem 2rem;
    
    &--primary {
      background-color: $primary-color;
      color: white;
    }
    
    &--secondary {
      background-color: transparent;
      border: 1px solid $primary-color;
    }
  }
}

My Take:

While many developers gravitate toward utility-based CSS frameworks like Tailwind, using SASS with BEM provides better separation of concerns and can be easier for beginners to understand. This approach also makes it clearer to see how styles relate to your component structure. The nesting capabilities of SASS make BEM much more maintainable than it would be in plain CSS.

Key Points:

• Create reusable components for Logo, Link, Hero Section, and Info Block
• Organize components into categories (Elements, Blocks)
• Set up component relationships and nested components
• Use enums for theme options (colors)
• Implement Dynamic Zones in Single Types for flexible content
• Understand how to structure data for optimal frontend consumption

My Take:

The way Paul designs these components shows excellent architectural thinking. By identifying common patterns in the design and turning them into reusable components, he’s creating a system that’s both flexible for content editors and maintainable for developers. The use of component relationships (like embedding the Link component within Hero and Info Block components) creates a powerful composition system.

Key Points:

• Create interfaces/types for your component props
• Build a reusable StrappyImage component for handling media from Strapi
• Implement the HeroSection component with proper styling
• Create the InfoBlock component with conditional rendering for reversed layout
• Add ReactMarkdown for rendering rich text content
• Set up Next.js Image configuration for Strapi media

// In types.ts
export interface LinkProps {
  id: number;
  text: string;
  href: string;
  isExternal: boolean;
}

export interface ImageProps {
  id: number;
  url: string;
  alternativeText?: string;
  width: number;
  height: number;
  formats?: {
    thumbnail?: { url: string };
    small?: { url: string };
    medium?: { url: string };
    large?: { url: string };
  };
}

export interface LogoProps {
  id: number;
  logoText: string;
  image: ImageProps;
}

// Base component type with common fields
interface BaseBlockProps {
  id: number;
  __component: string;
}

// Hero Section component
export interface HeroSectionProps extends BaseBlockProps {
  heading: string;
  image: ImageProps;
  logo: LogoProps;
  cta?: LinkProps;
  theme: 'turquoise' | 'orange';
}

// Info Block component
export interface InfoBlockProps extends BaseBlockProps {
  reversed: boolean;
  image: ImageProps;
  headline: string;
  content: string;
  cta?: LinkProps;
  theme: 'turquoise' | 'orange';
}

// In components/StrappyImage.tsx
import Image from 'next/image';
import { ImageProps } from '@/types';

function getStrapiMedia(url: string) {
  if (url.startsWith('http') || url.startsWith('//')) {
    return url;
  }
  return `${process.env.NEXT_PUBLIC_STRAPI_API_URL || 'http://localhost:1337'}${url}`;
}

export default function StrappyImage({
  image,
  className,
  priority = false,
  sizes = '100vw',
  height = 500,
  width = 600,
}) {
  if (!image || !image.url) {
    return null;
  }

  const imageUrl = getStrapiMedia(image.url);
  
  return (
    
  );
}

// In components/blocks/HeroSection.tsx
import StrappyImage from '../StrappyImage';
import { HeroSectionProps } from '@/types';

export default function HeroSection({
  heading,
  image,
  logo,
  cta,
  theme,
}: HeroSectionProps) {
  return (

); }

// First, install ReactMarkdown
// yarn add react-markdown

// In components/blocks/InfoBlock.tsx
import ReactMarkdown from 'react-markdown';
import StrappyImage from '../StrappyImage';
import { InfoBlockProps } from '@/types';

export default function InfoBlock({
  reversed,
  image,
  headline,
  content,
  cta,
  theme,
}: InfoBlockProps) {
  return (

); }

// In next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'http',
        hostname: 'localhost',
        port: '1337',
        pathname: '/uploads/**',
      },
    ],
  },
};

module.exports = nextConfig;

My Take:

Paul’s approach to component design follows best practices by creating reusable, well-typed components. The StrappyImage component is particularly useful, as it abstracts away the complexity of handling Strapi media URLs and provides a consistent interface for all images in the application. The use of TypeScript interfaces ensures type safety and helps prevent errors when working with data from the API.

Key Points:

• Create a BlockRenderer component that dynamically renders different block types
• Set up a query utility for retrieving data with proper population of relationships
• Implement the qs library for building complex Strapi queries
• Update the homepage to use the BlockRenderer
• Understand Strapi’s populate parameter for retrieving relational data

yarn add qs
yarn add @types/qs -D

// In data/loaders.ts
import qs from 'qs';
import { fetchAPI } from '@/utils/fetchApi';

const homepageQuery = qs.stringify({
  populate: {
    blocks: {
      on: {
        'blocks.hero-section': {
          populate: {
            image: {
              fields: ['url', 'alternativeText'],
            },
            logo: {
              populate: {
                image: {
                  fields: ['url', 'alternativeText'],
                },
              },
            },
            cta: {
              populate: '*',
            },
          },
        },
        'blocks.info-block': {
          populate: {
            image: {
              fields: ['url', 'alternativeText'],
            },
            cta: {
              populate: '*',
            },
          },
        },
      },
    },
  },
});

export async function getHomepageData() {
  try {
    const url = `/api/homepage?${homepageQuery}`;
    const data = await fetchAPI(url);
    return data;
  } catch (error) {
    console.error('Error fetching homepage data:', error);
    return null;
  }
}

// In components/BlockRenderer.tsx
import { ReactNode } from 'react';
import HeroSection from './blocks/HeroSection';
import InfoBlock from './blocks/InfoBlock';

interface BlockRendererProps {
  blocks: any[];
}

export default function BlockRenderer({ blocks = [] }: BlockRendererProps): ReactNode {
  return (
    <>
      {blocks.map((block) => {
        switch (block.__component) {
          case 'blocks.hero-section':
            return ;
          case 'blocks.info-block':
            return ;
          default:
            console.warn(`Unknown block type: ${block.__component}`);
            return null;
        }
      })}
    </>
  );
}

// In app/page.tsx
import { getHomepageData } from '@/data/loaders';
import { notFound } from 'next/navigation';
import BlockRenderer from '@/components/BlockRenderer';

export default async function HomeRoute() {
  const data = await getHomepageData();
  
  if (!data) {
    notFound();
  }
  
  const blocks = data.data.attributes.blocks || [];
  
  return (

  );
}

My Take:

The BlockRenderer pattern is one of the most powerful concepts in this tutorial. It creates a flexible system where non-technical users can build complex page layouts using predefined components, similar to how modern page builders work. As your project grows, you can easily extend this pattern by adding new block types to both Strapi and your BlockRenderer component.