Implementing file-based subpost routing

The subposts feature leverages Astro’s file-based routing to automatically detect parent-child relationships without any configuration. The entire implementation hinges on a simple observation: if a post ID contains a forward slash, it’s a subpost.

161
export function isSubpost(postId: string): boolean {
162
  return postId.includes('/')
163
}
164

165
export function getParentId(subpostId: string): string {
166
  return subpostId.split('/')[0]
167
}

This is a pretty elegant solution which requires no frontmatter configuration, no manual relationship mapping, and zero migration effort for existing posts.

Navigation complexity

One of the more intricate parts of this update was rethinking navigation. The original getAdjacentPosts() function assumed simple previous/next relationships. With subposts, we now have three distinct navigation contexts:

1
blog/
2
  getting-started.mdx
3
  react-tutorial/
4
    index.mdx
5
    components.mdx
6
    state.mdx
7
  advanced-patterns.mdx

Here’s how we handle this complexity:

40
export async function getAdjacentPosts(currentId: string): Promise<{
41
  newer: CollectionEntry<'blog'> | null
42
  older: CollectionEntry<'blog'> | null
43
  parent: CollectionEntry<'blog'> | null
44
}> {
45
  const allPosts = await getAllPosts()
46

47
  if (isSubpost(currentId)) {
48
    const parentId = getParentId(currentId)
49
    const parent = allPosts.find((post) => post.id === parentId) || null
50

51
    // Get all sibling subposts
52
    const posts = await getCollection('blog')
53
    const subposts = posts
54
      .filter(
55
        (post) =>
56
          isSubpost(post.id) &&
57
          getParentId(post.id) === parentId &&
58
          !post.data.draft
59
      )
60
      .sort((a, b) => a.data.date.valueOf() - b.data.date.valueOf())
61

62
    const currentIndex = subposts.findIndex((post) => post.id === currentId)
63

64
    return {
65
      newer: currentIndex < subposts.length - 1
66
        ? subposts[currentIndex + 1]
67
        : null,
68
      older: currentIndex > 0
69
        ? subposts[currentIndex - 1]
70
        : null,
71
      parent,
72
    }
73
  }
74

75
  // For parent posts, only navigate among other parent-level posts
76
  const parentPosts = allPosts.filter((post) => !isSubpost(post.id))
77
  const currentIndex = parentPosts.findIndex((post) => post.id === currentId)
78

79
  return {
80
    newer: currentIndex > 0 ? parentPosts[currentIndex - 1] : null,
81
    older: currentIndex < parentPosts.length - 1
82
      ? parentPosts[currentIndex + 1]
83
      : null,
84
    parent: null,
85
  }
86
}

As a TL;DR, subposts should only navigate among siblings and should be able to go up to their parent, while parent posts should only navigate among other parent-level posts.

Other considerations

• The breadcrumb component required careful thought to handle three distinct cases:

  70
  <Breadcrumbs
  71
    items={[
  72
      { href: '/blog', label: 'Blog', icon: 'lucide:library-big' },
  73
      ...(isCurrentSubpost && parentPost
  74
        ? [
  75
            {
  76
              href: `/blog/${parentPost.id}`,
  77
              label: parentPost.data.title,
  78
              icon: 'lucide:book-open',
  79
            },
  80
            {
  81
              href: `/blog/${currentPostId}`,
  82
              label: post.data.title,
  83
              icon: 'lucide:file-text',
  84
            },
  85
          ]
  86
        : [
  87
            {
  88
              href: `/blog/${currentPostId}`,
  89
              label: post.data.title,
  90
              icon: 'lucide:book-open-text',
  91
            },
  92
          ]),
  93
    ]}
  94
  />

  We append -text to book-open or file (for parent posts and subposts, respectively) to indicate the active post by differentiating it from inactive icons which would lack the text within the icon.

• The main blog listing (alongside other listings, e.g. filtering by tags, filtering by author) should exclude subposts to avoid cluttering the feed:

  7
  export async function getAllPosts(): Promise<CollectionEntry<'blog'>[]> {
  8
  const posts = await getCollection('blog')
  9
  return posts
  10
      .filter((post) => !post.data.draft && !isSubpost(post.id))
  11
      .sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf())
  12
  }

  Without this filter, your blog listing would show every subpost as a top-level entry, defeating the purpose of hierarchical organization.

• Desktop and mobile require fundamentally different approaches for displaying the subpost hierarchy. On desktop, we have the luxury of a persistent sidebar. On mobile, screen real estate demands integration with the sticky header system. This required careful slot management in the top-level Layout.astro:

  1
  <div class="bg-background/50 sticky top-0 z-50 border-b backdrop-blur-sm">
  2
      <Header />
  3
      <slot name="subposts-navigation" />
  4
      <slot name="table-of-contents" />
  5
  </div>

  The order is semantic here since subposts navigation comes before table of contents, creating a logical hierarchy of navigation options from broad (which post/subpost) to specific (which section).

• Not much testing has been done for deep nesting but my assumption is that it shouldn’t work. This is intentional to maintain simplicity, since at that point you might as well use a documentation site rather than a blogging site.