Polymorphic Feed Item Rendering

A feed schema that only supports a single activity type (post) cannot evolve to include likes, comments, follows, or shares without a full schema migration. When type support is added ad-hoc through if/else chains in the renderer, each new type adds a branch, tests, and cognitive overhead — the component becomes a maintenance liability under ISO 25010:2011. More concretely, the absence of a type discriminator on the Activity model means you cannot query or filter by activity type, which blocks every notification and analytics feature that depends on distinguishing activity kinds.

Add a type discriminator field to your activity or post schema, then replace branching renderer logic with a component factory in components/feed/ActivityRenderer.tsx.

// Prisma schema
model Activity {
  id        String   @id @default(cuid())
  type      String   // 'post' | 'like' | 'comment' | 'follow'
  userId    String
  targetId  String?
  content   String?
  createdAt DateTime @default(now())
  user      User     @relation(fields: [userId], references: [id])
}

// components/feed/ActivityRenderer.tsx
const renderers: Record<string, React.FC<{ activity: Activity }>> = {
  post: PostActivity,
  like: LikeActivity,
  comment: CommentActivity,
  follow: FollowActivity
}

export function ActivityRenderer({ activity }: { activity: Activity }) {
  const Component = renderers[activity.type]
  return Component ? <Component activity={activity} /> : null
}

This pattern lets you add new activity types by registering a new entry in renderers without touching the router or switch logic.