Add YouTube, Bilibili, and 小红书 links for AnnatarHe

[AnnatarHe]

Summary

• Extended the authors constant with a typed socials array so each author can carry multiple profile links.
• Added three new SVG icon components (youtube.astro, bilibili.astro, xiaohongshu.astro) following the existing external-link.astro pattern.
• Updated the footer to render the social icons inline next to the author name with hover styling consistent with the rest of the site.

New links for AnnatarHe

• YouTube: https://www.youtube.com/@annatarhe
• Bilibili: https://space.bilibili.com/173440264
• 小红书: https://www.xiaohongshu.com/user/profile/5b23cdfb11be1002d5f82bd8

Test plan

• pnpm astro check passes with 0 errors
• Visual check in pnpm dev — icons appear next to AnnatarHe in the footer and each opens the correct profile in a new tab
• Confirm footer wraps cleanly on mobile widths

---

Generated by Claude Code

[claude]

Code Review

Overview

This PR adds social profile links (YouTube, Bilibili, 小红书) for AnnatarHe in the footer. The approach is clean overall — typed data model in constants.ts, three new SVG icon components following the existing external-link.astro pattern, and updated footer rendering.

---

✅ What's done well

• TypeScript types (Author, AuthorSocial) are well-defined and properly applied to the authors array.
• Accessibility is handled correctly: SVGs have aria-hidden="true", anchor tags carry both aria-label and title with descriptive text.
• Security: New <a> tags correctly include rel="noopener noreferrer" alongside target="_blank".
• New icon components faithfully follow the existing external-link.astro pattern.
• flex-wrap gap-2 on the footer list is a good touch for mobile layout.

---

Issues and Suggestions

1. Existing author link is missing rel="noopener noreferrer" (security, pre-existing but worth fixing)

The existing x.link anchor in footer.astro uses target="_blank" without rel="noopener noreferrer":

<a href={x.link} target="_blank" class="hover:underline">

The new social icons got this right. This line should be updated to match:

<a href={x.link} target="_blank" rel="noopener noreferrer" class="hover:underline">

2. Duplicated frontmatter logic across all icon components (DX)

The className-merging frontmatter (lines 1–18) is identical in all three new icons and in external-link.astro. This is ~16 lines duplicated 4 times. Consider extracting it:

// src/utils/icon-classes.ts
export function resolveIconClasses(className?: string): string {
  const parts = className ? className.split(" ").map((x) => x.trim()) : [];
  if (!parts.some((x) => x.startsWith("h-"))) parts.push("h-4");
  if (!parts.some((x) => x.startsWith("w-"))) parts.push("w-4");
  return parts.join(" ");
}

Then in each icon's frontmatter:

import { resolveIconClasses } from "../../utils/icon-classes";
const cls = resolveIconClasses(Astro.props.className);

Not blocking, but worth doing if more icons are added.

3. finalClassNames should be typed (minor)

let finalClassNames = [];  // inferred as never[]

Should be:

let finalClassNames: string[] = [];

This is a latent TypeScript issue that pnpm astro check may not surface but is still incorrect.

4. type discriminant couples the data model to the render logic

The AuthorSocial.type union 'youtube' | 'bilibili' | 'xiaohongshu' is used as a direct switch in the footer:

{s.type === "youtube" && <IconYouTube />}
{s.type === "bilibili" && <IconBilibili />}
{s.type === "xiaohongshu" && <IconXiaohongshu />}

This is fine for three platforms. If it grows, a component map would be cleaner:

const iconMap = { youtube: IconYouTube, bilibili: IconBilibili, xiaohongshu: IconXiaohongshu };
const Icon = iconMap[s.type];
// <Icon />

Not a blocker today.

---

Test Plan gaps

Two items are unchecked in the PR's test plan:

• Visual check in pnpm dev
• Mobile width wrapping

These should be verified before merging, especially the mobile check since flex-wrap was added to accommodate icons.

---

Summary

The PR is functionally correct and well-structured. The main actionable items before merging are:

1. Add rel="noopener noreferrer" to the existing author <a> link (small security fix).
2. Type finalClassNames as string[] in the icon components.
3. Complete the visual/mobile checks in the test plan.

The duplication and icon-map suggestions are non-blocking improvements to consider in a follow-up.

[claude]

Code Review — PR #67: Add YouTube, Bilibili, and 小红书 links

Overview

Adds three social platform icons (YouTube, Bilibili, 小红书) to the site header for AnnatarHe, backed by a new socialLinks constant and three new Astro SVG icon components. Overall the intent is clear and the implementation is functional, but there are a few structural issues worth addressing.

---

Issues

🔴 PR description says "footer" but the change is in the header

The summary and test plan both reference the footer, but the only modified component is src/components/header.astro. This is a docs-only issue but worth correcting to avoid confusion for future reviewers.

🟡 socialLinks is not associated with any author

The constant is a standalone top-level export with no link to the authors array. The data model implies these links belong to AnnatarHe, but nothing encodes that relationship. If a second author gets social links, the design will need to be restructured anyway. Consider attaching socials directly to the relevant author entry now, consistent with what the PR description says was intended:

// constants.ts
export const authors = [
  {
    name: 'AnnatarHe',
    link: 'https://annatarhe.com',
    socials: [
      { type: 'youtube', url: '...', label: 'YouTube' },
      { type: 'bilibili', url: '...', label: 'Bilibili' },
      { type: 'xiaohongshu', url: '...', label: '小红书' },
    ],
  },
  // ...
];

🟡 Icon class-name logic is duplicated across all three new components

youtube.astro, bilibili.astro, and xiaohongshu.astro each contain the exact same 12-line className-parsing block, which is also present in external-link.astro. This makes four copies of the same logic. A small shared utility or a base component would eliminate the duplication. Even a simple helper in src/utils/icon.ts would help:

export function resolveIconClasses(className?: string, defaultH = 'h-4', defaultW = 'w-4') {
  const classes = className ? className.split(' ').map(x => x.trim()) : [];
  if (!classes.some(x => x.startsWith('h-'))) classes.push(defaultH);
  if (!classes.some(x => x.startsWith('w-'))) classes.push(defaultW);
  return classes.join(' ');
}

🟡 Icon type-switching in the template is brittle

The header iterates socialLinks but then manually checks s.type to decide which icon to render:

{s.type === "youtube" && <IconYouTube className="h-5 w-5" />}
{s.type === "bilibili" && <IconBilibili className="h-5 w-5" />}
{s.type === "xiaohongshu" && <IconXiaohongshu className="h-5 w-5" />}

Every new platform requires editing the template. If the author-level socials approach above is adopted, a simple icon registry object avoids this:

import IconYouTube from './icons/youtube.astro';
// ...
const iconMap = { youtube: IconYouTube, bilibili: IconBilibili, xiaohongshu: IconXiaohongshu };

Then in the template: const Icon = iconMap[s.type]; <Icon className="h-5 w-5" />

---

Minor Nits

• Inconsistent default sizes: external-link.astro defaults to h-6 w-6, the three new icons default to h-4 w-4. Not a bug (explicit sizes are always passed at callsites), but worth aligning.
• Inconsistent rel vs referrerpolicy: Existing channel links use referrerpolicy="no-referrer" (no rel="noopener"); the new links use rel="noopener noreferrer" (correct and more complete). Consider updating the existing links to the same pattern for consistency.
• Test plan items unchecked: The visual check and mobile wrap checks are unchecked in the test plan. Please verify these before merging — the header is visible on every page.

---

Positives

• as const on socialLinks gives TypeScript proper literal-type narrowing on type — good call.
• aria-label + aria-hidden="true" on SVGs is correct accessibility practice for icon-only links.
• rel="noopener noreferrer" on target="_blank" links is the right security posture.
• SVG paths look correct for each platform's brand icon.

---

Summary: The feature works, but the data model and code duplication should be addressed before merging. Most importantly, complete the visual/mobile checks in the test plan.