Problem
Current plugin overrides are flat - components like PostCard or Link are defined at the plugin level. This makes it impossible to:
- Override subcomponents per-page (e.g., different
PostCard for homepage vs tag page)
- Have typed component slot overrides for each page
- Compose pages from fully customizable subcomponent trees
Proposed Solution
Add structured page-level component overrides:
interface BlogPluginOverrides {
// Existing flat overrides for shared components
Link?: ComponentType<...>;
PostCard?: ComponentType<...>;
// New: Page-specific component slots
pages?: {
home?: {
Header?: ComponentType<PageHeaderProps>;
TagsList?: ComponentType<TagsListProps>;
PostsList?: ComponentType<PostsListProps>;
};
post?: {
Header?: ComponentType<...>;
OnThisPage?: ComponentType<...>;
PostNavigation?: ComponentType<...>;
};
// etc.
};
}
This allows consumers to surgically replace subcomponents on specific pages while keeping defaults elsewhere.
Alternatives
- Compound component patterns with dot notation (
BlogLayout.HomePage.Header)
- Render props for full control
- Context-based slot injection
Problem
Current plugin overrides are flat - components like
PostCardorLinkare defined at the plugin level. This makes it impossible to:PostCardfor homepage vs tag page)Proposed Solution
Add structured page-level component overrides:
This allows consumers to surgically replace subcomponents on specific pages while keeping defaults elsewhere.
Alternatives
BlogLayout.HomePage.Header)