Coder Legion - Recent posts tagged next

Intercepting Route In Next.js

Sat, 19 Sep 2026 10:14:13 +0000

Introduction

Intercepting route is a technique in Next.js that allows you to display a route from another part of your application, within the same current layout, without requiring the user to switch to a different context.

Intercepting route is always used with parallel route to build modals.

For example, when you click on an image on Instagram, what happens is:

1- A modal appears containing the image and its details, and the feed continues to run in the background.

2- The link changes from https://www.instagram.com to https://www.instagram.com/p/DYpin6_DOsV/

Intercepting route allows for the construction of this exact model: one link, and two different views depending on the user's approach.

Behind the Scenes

What happens exactly is that Next.js intercepts the navigation request for the given page, and instead of displaying the page, it passes it to a specific @slot, which is the Parallel Route

Folder Structure

The intercept route file is defined by creating a file that begins with (.), (..), or (..)(..), (...) where:

(.) is used to match a segment at the same level.

(..) is used to match a segment one level above.

(..)(..) is used to match a segment at two levels above.

(...) is used to match a segment at the root level. The importance of matching is evident when a user opens a new window or shares a link; the modal will not open, but the result will appear on a full standalone page. The intercept segment must match the full standalone page at the same level.

It should also be noted that the intercept route (...) relies on the route segment for matching, not the file system. The segment is part of the URL, while the @folder in the Parallel Routeis not considered part of the segment but rather a file system.

The images below illustrate the file structure :

Sources

1- Next.js

How to use parallel routing to build complex routing pattern in Next.js

Tue, 08 Sep 2026 05:44:23 +0000

Introduction

Parallel route is a term for a technique in the Next.js framework. It's the process that allows rendering one or more pages simultaneously or based on a specific condition within the same layout.
This concept is used in building dashboards to display multiple pages within a single dashboard, such as displaying the Teams page and the Analytics page, or in building modals that can be shared via URL.

How parallel routes render multiple sub-pages into a single parent layout. Source: Next doc

Create Parallel Route
parallel route is created by creating a folder called slots, written like this: @folder. Note: The @folder is created at the same level as the layout.tsx file.

file structure defines two explicit slots: @analytics and @team. Source: Next doc*

After creating @folder file, for example @team, containing a page named page.tsx, the slots for the rootlayout are added as props. It's worth noting that in Next.js, the rootlayout renders children.

// app/layout.tsx
export default function Layout(props: {
  children: React.ReactNode
  team: React.ReactNode
}) {
  return (
    <>
      {props.children}
      {props.team}  
    </>
  )
}

loading.tsx & error.tsx files
parallel route allows for the creation of a loading and error file specific to each slot, to display a loading spinner or error page for each route individually.

default.tsx file
The content of the slot that matches the URL, for example: en/team/members, is rendered. This is normal behavior. However, if there is no match between the slot and the URL, a fallback is needed to avoid the common 404 page not found error.

parallel route relies on the current layout. If the user navigates to a route that doesn't contain a dedicated page within the slot, Next.js searches for the default file to render it as a fallback. If the page refreshes, Next.js searches for the default.tsx file. If it's not there, it returns a 404 error page. It contains:

// default.tsx
export default function Default() {
return null
}

Usage

Modals

The importance of the parallel route lies in its ability to create overlay modals, similar to those found on Instagram. For example, when you click on an image, its details are displayed while the feed continues to run in the background. The link changes to something like /photo/flower. If you share the image link, the full image details are displayed, and the feed disappears from the background.

Complex Dashboards

As mentioned previously, you can display two or more pages on the same dashboard page, each with its own loading.tsx file, and each page's content is separate from the others.

Role-Based & Conditional Access

You can display different pages in the same layout based on the user. For example, if the user is an admin, you display the admin page, and if they are a member, you display the members page.
Within the layout page, the user session is checked, and the appropriate slot is returned.

export default function Layout(props: {
children: React.ReactNode
teamMember: React.ReactNode
admin: React.ReactNode
}) {
const role = getUserRole(); // Server-side check

return (
<div className="dashboard-wrapper">
{props.children}

{role === 'admin' ? props.admin : props.teamMember}

</div>

)
}

When should I use parallel route?

To determine this, you must answer certain questions such as:
1-Are there specific pages that I need to display on a single page?

2-Is there a component that needs to be displayed in a window above the main page without needing to close or disappear it?

3-Are there components in the same view whose display depends on the user's status (admin or regular user)?

References
Next.js
Medium

Poople Game

Mon, 15 Jun 2026 05:36:21 +0000

Wordle proved that one small puzzle a day, shared by everyone and finished in about a minute, can quietly become a habit. Poople takes that same one-a-day rhythm and points it at a word ladder. You start from a 4-letter word and change one letter at a time until you reach POOP. Every rung along the way has to be a real 4-letter word, and the fewer steps you take, the better your score.

The whole thing is free, runs in the browser, and needs no account. Your streak and stats live in your own browser, so there is nothing to sign up for and nothing to install. Open the page, solve the puzzle, copy a spoiler-free grid, and get on with your day.

The small problem it solves

Most of us already keep a little stack of daily puzzles we open with coffee. The friction shows up fast, though. Some games want an account before you can play. Some bury the puzzle under newsletters and pop-ups. Some take longer than the coffee does. Poople is built to be the opposite of all that. The page is light, the rules fit in one sentence, and a typical day takes under a minute.

How it works

A word ladder is an old idea. Lewis Carroll wrote about it in 1877 and called it Doublets. You connect two words by changing one letter at a time while keeping a valid word at every step. In Poople the destination is always POOP, which gives the game its name and a fixed target you can plan around. A new puzzle goes live every day at 08:00 UTC, and every player in the world gets the same starting word that day.

What makes it satisfying is the planning. You are steering through a graph of words, looking a few moves ahead, and trying to land on the shortest route. It rewards a different muscle than a guessing game does, closer to finding a path through a maze than to filling in blanks.

A solve looks like this

Say the day's word is COAT.

COAT becomes COAL
COAL becomes COOL
COOL becomes COOP
COOP becomes POOP

That path takes four steps. There may be an even shorter route hiding in the dictionary, and par is that shortest possible path for the day. Matching par is the result to chase, and hunting for it is where the game gets its hooks into you.

Three ways to play

The daily puzzle is the main event. One shared word ladder for the whole world, refreshed every morning, with a spoiler-free grid you can post when you finish.

Poople Unlimited is a free practice mode. Press shuffle for a fresh random starting word whenever you want, with no wait for the next day. It keeps your daily streak untouched, so it is a relaxed place to warm up before the daily puzzle or to keep going after you have solved it.

Poople Answers is the archive. Once a puzzle closes, its full solution is published the next day. Each entry shows the verified shortest path, progressive hints you can reveal one at a time, short definitions for the bridge words along the way, and an in-page solver that finds the shortest route to POOP from any 4-letter word you type in.

Details that make the habit stick

Spoiler-free sharing. Copy a small grid that shows your path without giving away the words you used, in the same spirit as the Wordle share.

Local stats. Wins, best streak, and average steps are saved on your device, so your history follows your browser instead of a login.

Keyboard and touch. Type on a physical keyboard or tap the on-screen keys, on desktop or mobile.

Par scoring. Every puzzle has a known shortest path, so there is always a clear goal beyond simply reaching POOP.

Fast and clean. The page is light and free of clutter, so it loads quickly and starts the moment it opens.

On price there is not much to cover. Poople is free, there is no account wall, and there is nothing to download. The daily game stays the daily game, and the practice mode and the archive sit alongside it for anyone who wants more.

Stack notes for the engineers in the room

Poople runs on Next.js 15 with the App Router, deployed to Cloudflare through OpenNext. Data lives in Cloudflare D1, which is SQLite, with Drizzle ORM on top, and the runtime leans on Cloudflare Workers, Durable Objects, KV, and R2. Copy and translations go through next-intl.

The part I had the most fun building is the answers pipeline. The day's solution is never written by hand. A breadth-first search over the graph of every valid 4-letter word computes par and a verified shortest path, so each archived answer comes from one deterministic source of truth. A Cloudflare cron trigger publishes the previous day's answer every morning, and at the same time it generates the short bridge-word definitions and a one-line note for that puzzle through an LLM via OpenRouter, then stores them in D1 so the pages stay static and cheap to serve. Each past puzzle gets its own page at /answer/{number}-{word}, statically generated with incremental static regeneration, which turns the archive into a clean programmatic surface that grows by one page a day.

On the roadmap: more variety in starting words, an optional harder mode, and a small public endpoint for the daily puzzle so people can build their own front-ends and bots around it.

Try it

Play today's puzzle at https://pooplegame.com. The practice mode is at https://pooplegame.com/unlimited, and the answers archive is at https://pooplegame.com/answer.

If you give it a try, I would love to hear two things. First, when you get stuck, what is your instinct, do you swap the vowel first or work backward from POOP? Second, for the developers here, would a daily-puzzle API be worth building out? Feedback and bug reports are very welcome.

Streamlining Your Next.js Project with Private GitHub/Gitlab Repositories as NPM Packages

Wed, 10 Sep 2025 16:53:12 +0000

Using Private GitHub/Gitlab Repos in Your Next.js Projects

Imagine this scenario: you're working on a super cool Next.js project, and you have some shared code that you'd like to use across multiple projects. You don't really want to make it public by publishing it to npm. You also don't want to pay for an npm account to make your repos private. Is there a way to keep it private, secure, yet reusable? You bet!

In the world of Next.js v13.4 and beyond, using private GitHub or GitLab repositories as npm packages is not only possible, it's also quite straightforward. The steps vary for older versions of Next.js before v13.4 (those using Page Router) and won't be covered in this blog.

Essentially, we’ll be taking code from a private GitHub or GitLab repository and using it directly in our Next.js project. This method is perfect when you have shared components, utilities, or any other code that you need to reuse across several projects, but don't want to expose to the world (or persevere through the overhead of setting up an npm account).

Today, I'll walk you through the steps to make this happen. Buckle up, because we're about to make your life a whole lot easier!

Step 1: Create Your Private GitHub Repo

This is where your shared code will live. If you already have one, fantastic. If not, go ahead and create a new private repository on GitHub or Gitlab.

Step 2: Generate a GitHub Access Token

Navigate to your GitHub settings (or Gitlab settings for those using Gitlab).
Create a new personal access token (make sure it only has read access).
Copy this token and keep it safe (you’ll need it soon).

Step 3: Set Up Your Shared Repo

In your shared repository's package.json, set the name field to whatever you'd like to call your package, e.g., "package-name": "1.0.0".

Step 4: Update Your Next.js Project’s `package.json`

In the package.json of the Next.js project where you want to use your shared code:

{
  "dependencies": {
    "package-name": "git+https://<github_token>:*Emails are not allowed*/<user>/<repo>.git#branch-name"
  }
}

Replace <github_token>, <user>, <repo>, and branch-name with the appropriate values from your setup.

Final Steps: Configuration in Next.js

In your next.config.js, add the following:
```
module.exports = {
    transpilePackages: ["package-name"],
};
```
This tells Next.js to also compile your typescript code from the shared repo and transform it to javascript - that's basically what transpile means; a combination of the word 'transform' and 'compile'. Without this, you'll get module parsing errors for your typescript (.ts) files.
If you're using Tailwind CSS, update your tailwind.config.js to include your shared package:
```
module.exports = {
    content: [
        "./node_modules/<package_name>/src/**/*.{js,ts,jsx,tsx,html,mdx}",
        "./node_modules/<package_name>/app/**/*.{js,ts,jsx,tsx,html,mdx}",
    ],
    //… other tailwind config
};
```
Replace <package_name> with the name of your shared repo. Also, if you aren't using the src folder, feel free to adjust the values according to your setup
Now run npm install and voila! your shared package has now been installed as an NPM dependency and you can use it in your project.

Before We Finish Just Yet

Always remember to update the version number in your package.json with a higher value each time you make a change to your shared repo. After words, run npm update <package_name> where <package_name> is the name of your shared package/repo. This will ensure that your changes in the shared package's changes are published to your project.

Conclusion

Incorporating private GitHub repos as npm packages in your Next.js projects not only keeps your code organized and secure but also significantly boosts your productivity. You no longer need to duplicate code or compromise your privacy by publishing sensitive code to public registries.

So, what are you waiting for? Dive in and streamline your projects today. And remember, it’s these smart shortcuts that often make a big difference in the efficiency and success of your development efforts.

A deep dive into Next.js Rendering for Performance and SEO

Sat, 08 Feb 2025 14:30:02 +0000

Introduction

Hey Everyone, Good to see you back! Rendering in Next.js is a crucial aspect that determines how your web pages are generated and served to users. It can be understood as the process of converting code into user interfaces that users can interact with.

Unlike traditional React applications that rely heavily on Client-Side Rendering (CSR), Next.js pre-renders pages by default, generating HTML in advance, which offers improved performance and SEO benefits.

Types of Rendering in Next.js

Next.js offers several rendering strategies, giving developers the flexibility to choose the best approach for each page or application. The rendering methods available in Next.js include Static Site Generation (SSG), Server-Side Rendering (SSR), Client-Side Rendering (CSR), and Incremental Static Regeneration (ISR).

Static Site Generation (SSG)

This approach creates HTML pages at build time, rather than generating them on demand for each user request. This means that every page of your website is pre-built and stored as static files, and ready to be served instantly when a user accesses the site. The primary benefits of SSG include improved performance, enhanced security, and cost-effectiveness.

Why Use Static Site Generation?

Performance: Since the HTML files are pre-generated, they load much faster than dynamically generated pages.
Security: Static sites have fewer vulnerabilities because they do not rely on databases or server-side processing.
Cost-Effectiveness: Hosting static files is generally cheaper than hosting dynamic sites.
Simplicity: Static sites are easier to deploy and maintain.

Implementing SSG

npx create-next-app ssgShowcase
cd ssgShowcase

Followed by:

// pages/index.js
export default function Home({ products }) {
   return (
      <div>
      <h1>SSG showcase</h1>
      <ul>
          {products.map(product => (
          <li key={product.id}>
          <h2>{product.title}</h2>
          <p>{product.description}</p>
          <img src={product.thumbnail} alt={product.title} width="100" />
          </li>
          ))}
      </ul>
      </div>
     );
    }

    export async function getStaticProps() {
    const res = await fetch('https://dummyjson.com/products?limit=10');
    const data = await res.json();
    const products = data.products;

    return {
    props: {
      products,
    },
  };
  }

In this example, we used the getStaticProps function provided by Next.js to fetch data at build time. When you run npm run dev, Next.js will execute this function, fetch the data from the API, and generate static HTML for each product.

Server Side Rendering (SSR)

Server-Side Rendering (SSR) is a rendering technique where the HTML for a web page is generated on the server in response to each request. This means that every time a user requests a page, the server dynamically generates the HTML and sends it to the browser. Unlike Static Site Generation (SSG), where pages are pre-built at build time, SSR ensures the content is always up-to-date. It uses the getServerSideProps function to fetch data on each request, making it ideal for dynamic content that requires real-time updates or personalized data.

Why Use Server-Side Rendering?

Dynamic Content: SSR is ideal for applications that display frequently updated or personalized content.
SEO for Dynamic Pages: Like SSG, SSR helps with SEO by providing fully rendered HTML to search engine crawlers.
Data Fetching at Request Time: SSR allows you to fetch data on each request, ensuring that the content is always current.

Implementing SSR

npx create-next-app ssrShowcase
cd ssrShowcase

Followed by:

  // pages/index.js
  export default function Home({ meal }) {
  return (
    <div>
         <h1>Recipe of the Day</h1>
         <h2>{meal.strMeal}</h2>
         <img src={meal.strMealThumb} alt={meal.strMeal} width="200" />
         <p>Category: {meal.strCategory}</p>
         <p>Instructions: {meal.strInstructions}</p>
    </div>
    );
  }

  export async function getServerSideProps() {
  const res = await fetch('https://www.themealdb.com/api/json/v1/1/random.php');
  const data = await res.json();
  const meal = data.meals[0];

  console.log("Meal Data from API:", meal);
  return {
    props: {
      meal,
    },
   };
  }

Check the terminal or console where you started the Next.js development server. Each time you refresh the page, you'll see the console.log output, including the data fetched from the API and refreshes.

Client Side Rendering (CSR)

In this rendering technique, browser renders the web page using JavaScript. It downloads a minimal HTML page along with all the necessary JavaScript. The JavaScript then updates the DOM (Document Object Model) and renders the page. Unlike Server-Side Rendering (SSR) and Static Site Generation (SSG), where the server pre-renders the HTML, CSR generates the content on the client's device.

Why Use Client-Side Rendering?

Interactivity: CSR is ideal for highly interactive web applications where the user interface needs to respond quickly to user actions.
Dynamic Updates: CSR allows you to fetch and render data on-the-fly, enabling dynamic content updates without refreshing the entire page.
Reduced Server Load: With CSR, the server only sends raw data, reducing the load on the server compared to SSR.

Implementing CSR

npx create-next-app csrShowcase
cd csrShowcase

Followed by:

// pages/index.js
import React, { useState, useEffect } from 'react';

export default function Home() {
    const [data, setData] = useState(null);
    const [loading, setLoading] = useState(true);
    const [error, setError] = useState(null);

    useEffect(() => {
       async function fetchData() {
       try {
         const res = await fetch('https://api.quotable.io/random');
         const json = await res.json();
         setData(json);
       } catch (error) {
          setError(error);
       } finally {
             setLoading(false);
       }
     }
    fetchData();
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  if (!data) return <p>No data</p>;

  return (
     <div>
       <h1>Quote</h1>
       <p>{data.content}</p>
       <p>- {data.author}</p>
     </div>
   );
}

In the above example, we use an important hook called useEffect to fetch data from the Quotable API on the client side. The hook runs after the component has rendered. It fetches the data and updates the component's state, triggering a re-render with the new data. So, When you load the page for the first time, you might notice a slight delay because the page isn't fully rendered until all the JavaScript is downloaded, parsed, and executed. Also, you will see "Loading…" text. Once the data is fetched from the API, the page will be rendered with the quote and author. Refreshing the page will fetch new data and update the content dynamically.

Incremental Site Regeneration (ISR)

ISR is a rendering technique in Next.js that allows you to create or update static pages after you've built your application. It enables developers and content editors to use static-generation on a per-page basis, without needing to rebuild the entire application. With ISR, you can retain the benefits of static while scaling to millions of pages. It’s a fairly new way to update static pages and is mainly used for custom built websites.

ISR in Next.js takes the best of static site generation and server-side rendering. Imagine a request comes in for a page, the server first checks if a static version of the page is available. If it exists, the static page is immediately returned. Meanwhile, the server looks at the age of the page. If it's older than a predefined interval, the server will regenerate the page in the background and replace the old one.

ISR uses getStaticProps to fetch data. Add the revalidate property to getStaticProps to use ISR. The revalidate property specifies how often a page should be regenerated. Once this period elapses, the next request to the page triggers a regeneration of the page in the background. While the page is being regenerated, the old version of the page continues to be served to users. Upon completion of the regeneration, the old version of the page is replaced with the new one for subsequent requests. This gives you the flexibility to have constantly updating content on your website without compromising on the advantages of static generation.

Why Use Incremental Static Regeneration?

Faster Builds: Reduces build times, especially for large-scale applications.
Dynamic Content Updates: Allows for dynamic content updates without sacrificing performance.
Scalability: Allows you to retain the benefits of static while scaling to millions of pages.

Implementing ISR

npx create-next-app isrShowcase
cd isrShowcase

Followed by:

// pages/index.js
export async function getStaticProps() {
     const res = await fetch('https://api.quotable.io/random');
     const data = await res.json();

     return {
       props: {
        quote: data.content,
        author: data.author,
     },
      revalidate: 10, // I have added here for every 10 seconds
     };
  }

  export default function Home({ quote, author }) {
     return (
       <div>
         <h1>Random Quote</h1>
         <p>{quote}</p>
         <p>- {author}</p>
       </div>
      );
   }

Conclusion

Next.js offers a versatile suite of rendering techniques, each designed to optimize different aspects of application development. While SSG should generally be the default choice for its superior performance and SEO with static content, SSR becomes essential for highly dynamic content requiring real-time updates, and CSR remains valuable for interactive application. ISR shines in managing large datasets and content updates without full rebuilds. Understanding the strengths and trade-offs of each method allows you to tailor rendering strategies to meet specific project needs, creating applications that are fast, scalable, and optimized.

Thank you for making it to the end! I hope you enjoyed the article, please consider sharing it with someone who might benefit from it.
Feel free to reach out to me on Twitter.

Thankyou Once Again!!

Coder Legion - Recent posts tagged next

Intercepting Route In Next.js

Introduction

Behind the Scenes

Folder Structure

Sources

How to use parallel routing to build complex routing pattern in Next.js

Poople Game

The small problem it solves

How it works

A solve looks like this

Three ways to play

Details that make the habit stick

Stack notes for the engineers in the room

Try it

Streamlining Your Next.js Project with Private GitHub/Gitlab Repositories as NPM Packages

Using Private GitHub/Gitlab Repos in Your Next.js Projects

Step 1: Create Your Private GitHub Repo

Step 2: Generate a GitHub Access Token

Step 3: Set Up Your Shared Repo

Step 4: Update Your Next.js Project’s package.json

Final Steps: Configuration in Next.js

Before We Finish Just Yet

Conclusion

A deep dive into Next.js Rendering for Performance and SEO

Step 4: Update Your Next.js Project’s `package.json`