Skip to content

feat(sections): implement modular page sections with reusable schemas - #3

Open
srikishore5727 wants to merge 6 commits into
feature/dynamic-routing-sanity-cmsfrom
feature/reusable-sections
Open

srikishore5727 wants to merge 6 commits into
feature/dynamic-routing-sanity-cmsfrom
feature/reusable-sections

Conversation

@srikishore5727

Copy link
Copy Markdown
Contributor

What does this PR do?

  • Introduces modular section-based content modeling in Sanity (Hero, Text-Image, Feature List).
  • Updates Page schema to support dynamic sections array instead of hardcoded layout fields.
  • Enhances Next.js dynamic page route to fetch and inspect sections data via GROQ for testing.
  • Adds initial frontend console/debug rendering to verify CMS-driven structure.
  • Registers new section schemas and organizes schema structure for scalability.

What steps does your reviewer have to take to test this PR manually?

  1. Run the application using npm run dev.
  2. Open Sanity Studio at http://localhost:3000/studio.
  3. Open the Page document type from the left sidebar.
  4. Open an existing Page object (e.g., Home or About).
  5. Add multiple sections (Hero / Text Image / Feature List), reorder them, and click Publish.
  6. Visit http://localhost:3000/home on the frontend.
  7. Verify sections data appears in the terminal console and JSON preview on the UI.
  8. Confirm there are no hardcoded hero/banner fields and the layout is driven entirely by the sections array.

Pull Request standards checklist - Please check off

  • This Branch will be carrying one single responsibility - feature/bugfix/style/refactor...
  • I have followed conventional commit messages and descriptive Branch naming.
  • My PR has descriptive folder/file names that I have worked on.

Testing checklist - Please check off

  • I have performed manual testing on my local to validate all changes.

Definition of Done - Please check off

  • My code is well tested and I have confidence my code works as I expect in a variety of situations.
  • I have lint and format code is enabled when the file is saved and I have fixed all errors highlighted by lint.
  • I have deleted all non-descriptive comments and dead code from the files I've touched.
  • I have rebased my branch with the base branch I want to merge into and all the commits in this PR are my own.

@mergemitra

mergemitra Bot commented Jan 30, 2026 •

Copy link
Copy Markdown

Change Summary

Implements modular Sanity-driven page sections by routing section data through Next and the new PageRenderer. Adds Hero, Text-Image, and Feature List components plus section mapping/types to render dynamic blocks. Updates Sanity schemas and config to support the new section types and remote Sanity imagery.

File Changes
File Summary
app/[slug]/page.tsx Updates dynamic page route to query sections via GROQ and renders PageRenderer.
components/PageRenderer.tsx Adds renderer to map section data to typed components with console logging.
components/PageRenderer.type.ts Defines SectionProps union and renderer props for hero, text-image, feature sections.
components/sectionMap.ts Registers section types mapping to their respective React components.
components/sections/FeatureListSection.tsx Adds feature list section layout showing tiled feature cards.
components/sections/FeatureListSection.type.ts Defines feature list section props with keyed feature title and description.
components/sections/HeroSection.tsx Introduces hero section component with background image and overlay text.
components/sections/HeroSection.type.ts Specifies hero section props including heading, subheading, and background image.
components/sections/TextImageSection.tsx Creates text-image section handling alignment and optional imagery.
components/sections/TextImageSection.type.ts Describes text-image section props with text, image, and alignment options.
next.config.ts Allows Sanity CDN images through Next.js remote image configuration.
sanity/schemaTypes/index.ts Registers page and new section schemas for unified Sanity schema collection.
sanity/schemaTypes/page.ts Replaces static fields with sections array linking to modular section types.
sanity/schemaTypes/sections/featureListSection.ts Adds Sanity feature list section schema with nested feature objects.
sanity/schemaTypes/sections/heroSection.ts Introduces Sanity hero section schema capturing heading, subheading, image.
sanity/schemaTypes/sections/textImageSection.ts Defines Sanity text-image section schema including text, image, and alignment.
tsconfig.json Adds sections components to glob includes for TypeScript compilation.

Based on f8711bf...245d72a

@mergemitra

mergemitra Bot commented Jan 30, 2026

Copy link
Copy Markdown

PR Scorecard

Score

Communication Quality Code Correctness & Design Quality Test Quality & Coverage Code Readability & Maintainability
Scoring Methodology

Communication Scoring Framework

The overall communication score is a weighted average:

Dimension Weight Evaluates
PR Description Quality 60% Title format (conventional commits) + Description clarity (what changed & why)
PR Size & Scope 25% Appropriate sizing, scope cohesion, and justification for size
Commit Messages 15% Conventional commits format, atomic & descriptive changes

Formula: (Description x 0.6) + (PR Size x 0.25) + (Commits x 0.15)

Code Scoring Framework

The scorecard evaluates code using 3 key reviewer questions:

Reviewer Question Category
Is this the right solution, implemented the right way? Code Correctness
Would this catch bugs if the code broke tomorrow? Test Quality
Can someone new understand and safely modify this in 6 months? Maintainability
PR Communication Notes

Description Quality

  • ✅ Title follows conventional commits and clearly scopes the change to sections
  • ✅ Description explains what changed and includes detailed manual testing steps
  • ❌ Checklists are left unchecked; either complete them or remove if not required
  • ❌ Description misses notable changes like suppressHydrationWarning and removal of page.description field in schema

PR Size & Scope

  • ✅ Size is small (143+/29-, 7 files) and easy to review
  • ✅ Changes stay focused on Sanity section schemas + page fetch/debug for sections

Commit Messages

  • ✅ Single commit uses conventional format and matches the PR scope clearly
  • ✅ Commit message is descriptive and not generic, making history easy to scan

Issue Notes

Code Correctness & Design Quality

  • 🟠 sections?: any[] at app/[slug]/page.tsx:11 bypasses type checking and can hide runtime failures when rendering section variants
  • 🟠 Query/UI still expects description at app/[slug]/page.tsx:18 but the Page schema removed it, so the UI may always render blank and editors lose that content
  • 🟠 Logging the full page doc at app/[slug]/page.tsx:46 can leak CMS content to server logs and adds noise on every request
  • 🟠 Rendering raw CMS JSON at app/[slug]/page.tsx:57 can unintentionally expose internal CMS structure/content to end users if it ships beyond debugging
  • 🟠 suppressHydrationWarning at app/layout.tsx:26 masks server/client render mismatches, making real hydration bugs harder to detect and potentially shipping broken UI states
  • 🟠 Missing required validation on slug at sanity/schemaTypes/page.ts:16 allows publishing pages without a route key, causing page fetches by slug to fail at runtime

Test Quality & Coverage

  • 🟠 No automated tests added for new sections-based routing/schema at app/[slug]/page.tsx:16, sanity/schemaTypes/page.ts:8 so regressions in GROQ projections or section rendering won’t be caught
💬 Minor Issues (Nitpicks)

Code Correctness & Design Quality

  • 💬 alignment at sanity/schemaTypes/sections/textImageSection.ts:25 has no required validation/initial value, so documents can be saved without alignment and downstream rendering must guess a layout

Code Readability & Maintainability

  • 💬 Commented-out query at app/[slug]/page.tsx:14 is dead code that will drift and confuse future edits
  • 💬 Hardcoded section field projection at app/[slug]/page.tsx:20 returns lots of irrelevant null fields and makes adding new section types more brittle than using _type-specific projections
  • 💬 suppressHydrationWarning at app/layout.tsx:26 needs an inline comment explaining the root cause and when it can be removed to avoid normalizing hidden hydration issues
  • 💬 Inconsistent defineField(...) formatting at sanity/schemaTypes/page.ts:8 reduces readability and makes future schema edits more error-prone
  • 💬 Feature item fields at sanity/schemaTypes/sections/featureListSection.ts:16 omit titles/validation (and don’t use defineField), making it easier to save incomplete items and degrading Studio UX
  • 💬 Misleading file header comment (heroSection.js) at sanity/schemaTypes/sections/heroSection.ts:1 can confuse readers and tooling expectations in a TS codebase
  • 💬 Inconsistent indentation/quoting at sanity/schemaTypes/sections/textImageSection.ts:1 makes the schema harder to scan and maintain alongside the other section definitions

Based on f8711bf...40ebde5

name: 'heroBanner',
title: 'Hero Banner',
type: 'image',
name: 'slug',

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

Make slug required again so pages can’t be published without a route key.

defineField({
  name: 'slug',
  ...,
  validation: (Rule) => Rule.required(),
})

Comment thread app/[slug]/page.tsx Outdated
type PageDoc = {
title: string
description?: string | null
sections?: any[] //newly added for testing

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

Replace any[] with a discriminated union (or unknown + runtime narrowing) so section rendering changes are type-checked.

type PageSection = HeroSection | TextImageSection | FeatureListSection;
...
sections?: PageSection[];

Comment thread app/layout.tsx Outdated
}>) {
return (
<html lang="en">
<html lang="en" suppressHydrationWarning>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

Avoid globally suppressing hydration warnings; fix the underlying mismatch (or scope suppression to the smallest possible subtree).

<html lang="en">
  <body className={...}>

@mergemitra

mergemitra Bot commented Jan 30, 2026

Copy link
Copy Markdown

PR Overview

PR Type: Feature

Focus Areas for Architect Review

  • Decide the long-term contract for sections (typed union + GROQ _type-specific projections + _key fetching) so adding new sections doesn’t require brittle query/type churn.
  • Confirm whether description is intentionally removed from the Page model; if yes, remove it from queries/UI, and if not, add it back to the schema to prevent silent content loss.
  • Hydration mismatch suppression in app/layout.tsx should be treated as temporary; identify the real mismatch source rather than masking warnings.
  • Testing strategy is currently missing for the new schema/query path; add at least one integration test that asserts section projections/shapes and a basic render path to prevent regressions.
PR Insights

Potential PR Improvements

  • Correctness: Avoid any[] for sections; model section types explicitly.
  • Correctness: Keep queries and UI aligned with schema field removals.
  • Robustness: Remove debug logging and raw JSON rendering before shipping.
  • Robustness: Avoid suppressHydrationWarning unless root cause is fixed.
  • Testing: Add automated tests for GROQ projections and section rendering.

PR Strengths

  • Description Quality: PR description gives clear steps for manual verification.
  • Code Maintainability: Sections are split into reusable, modular schema definitions.
  • Best Practices: Schema registration is centralized for easier scalability.
  • Correctness: Page schema supports reorderable sections via an array.
  • Documentation: Manual testing checklist clarifies expected behavior changes.

@mergemitra

mergemitra Bot commented Jan 30, 2026

Copy link
Copy Markdown

Tip

Need another review?

Tag me and say rereview for re-analysis after you have fixed all the issues.

@cw-pr-agent rereview

@vaibhav-cw

Copy link
Copy Markdown
Collaborator

@cw-pr-agent rereview

@mergemitra

mergemitra Bot commented Jan 30, 2026

Copy link
Copy Markdown

PR Scorecard

Score

Communication Quality Code Correctness & Design Quality Test Quality & Coverage Code Readability & Maintainability
Scoring Methodology

Communication Scoring Framework

The overall communication score is a weighted average:

Dimension Weight Evaluates
PR Description Quality 60% Title format (conventional commits) + Description clarity (what changed & why)
PR Size & Scope 25% Appropriate sizing, scope cohesion, and justification for size
Commit Messages 15% Conventional commits format, atomic & descriptive changes

Formula: (Description x 0.6) + (PR Size x 0.25) + (Commits x 0.15)

Code Scoring Framework

The scorecard evaluates code using 3 key reviewer questions:

Reviewer Question Category
Is this the right solution, implemented the right way? Code Correctness
Would this catch bugs if the code broke tomorrow? Test Quality
Can someone new understand and safely modify this in 6 months? Maintainability
PR Communication Notes

Description Quality

  • ✅ Title still follows conventional commits with clear scope and summary
  • ✅ Manual testing steps are still detailed and reproducible
  • ❌ Checklist items are still all unchecked; complete them or remove the checklist blocks
  • ❌ Steps mention JSON preview UI, but code now renders and no
     JSON dump

PR Size & Scope

  • ✅ This update adds ~155 lines across 14 files, mainly PageRenderer + section components
  • ✅ Added files stay cohesive around sections rendering and Sanity-driven layout

Commit Messages

  • ✅ New commit 'fix: resolve hydration errors and improve type safety...' is conventional and descriptive
  • ❌ New commit 'feat: make components to display iinfo...' has a typo and vague summary; use clearer scope/wording going forward

Issue Notes

Code Correctness & Design Quality

  • 🟠 [UNRESOLVED] Debug logging at app/[slug]/page.tsx:48 prints CMS section content into server logs and can leak data / add noise in production
  • 🟠 [UNRESOLVED] suppressHydrationWarning at app/layout.tsx:29 hides real server/client markup mismatches, making hydration bugs harder to detect and debug
  • 🟠 Type assertion on section component at components/PageRenderer.tsx:12 can pair the wrong component/props and hide runtime render errors when section types evolve
  • 🟠 Using array index as React key at components/PageRenderer.tsx:19, components/sections/FeatureListSection.tsx:10 can cause incorrect UI/state when sections/features are reordered in Sanity
  • 🟠 backgroundImage/image typed as string at components/sections/HeroSection.type.ts:5, components/sections/TextImageSection.type.ts:4 but passed to urlFor(...) at HeroSection.tsx:11, TextImageSection.tsx:18, risking runtime failures and incorrect query typing
  • 🔴 remotePatterns entry at next.config.ts:6 lacks pathname, which can prevent Sanity images from loading or fail Next config validation

Test Quality & Coverage

  • 🟠 [UNRESOLVED] No automated tests for sections-based rendering/query at app/[slug]/page.tsx:43, components/PageRenderer.tsx:6 so GROQ/type regressions can ship unnoticed

Code Readability & Maintainability

  • 🟠 Missing explicit return types for exported components at app/[slug]/page.tsx:43, components/PageRenderer.tsx:6, components/sections/HeroSection.tsx:6 reduces TS enforcement and can hide invalid render paths
💬 Minor Issues (Nitpicks)

Code Readability & Maintainability

  • 💬 console.warn at components/PageRenderer.tsx:15 will run on the server for every request with an unknown section type; consider failing fast or logging only in dev to reduce log noise
  • 💬 Mixed quoting/semicolons at components/PageRenderer.type.ts:1-9 compared to nearby files makes formatting inconsistent and harder to maintain
  • 💬 next/image with fill at components/sections/HeroSection.tsx:10 should include sizes to avoid Next warnings and improve responsive image selection
  • 💬 Odd comma-leading formatting in tsconfig.json:32 makes the config harder to read/maintain; prefer standard trailing commas and glob patterns

Based on 40ebde5...3908fc5

Comment thread components/sectionMap.ts Outdated
Comment thread components/PageRenderer.tsx Outdated
Comment thread next.config.ts
@mergemitra

mergemitra Bot commented Jan 30, 2026

Copy link
Copy Markdown

PR Overview

PR Type: Feature

Focus Areas for Architect Review

  • Define/standardize the sections data contract (GROQ projection should always include _type + _key + consistent image shapes) so the renderer can stay type-safe as section types grow.
  • Decide whether hydration warning suppression and server-side debug logging are acceptable in production, and if not, what the team’s “debug only” policy is.
  • Establish a minimal testing strategy for CMS-driven rendering (at least one integration-ish test that validates section projection + render).
Rereview Impressions

Progress Since Last Review

  • sections is now a typed union instead of any[] (good improvement for safety).
  • Raw JSON debug rendering was removed from the page output.
  • slug is now required in the Page schema.
  • Hydration suppression was reduced (removed from <html>), though it still exists on <body>.

New Issues Introduced (if any)

  • Section components type image fields as string while calling urlFor(...), which undermines type safety and risks runtime issues.
  • Renderer still uses index-based keys for reorderable arrays and relies on a type assertion to select components.
  • Next image remotePatterns likely needs a pathname to reliably allow Sanity CDN images.
PR Insights

Potential PR Improvements

  • Correctness: Fix next.config remotePatterns pathname for Sanity images.
  • Robustness: Remove server console logging of CMS sections in production.
  • Correctness: Avoid type assertion; enforce sectionMap and props typing.
  • Code Maintainability: Use stable keys from CMS, not array indexes.
  • Testing: Add automated tests for GROQ projections and section rendering.

PR Strengths

  • Code Maintainability: Modular section components and central sectionMap improve extensibility.
  • Correctness: Replaced any sections with typed discriminated union props.
  • Robustness: Renderer safely returns null when sections are missing.
  • Correctness: Added required validation for slug in Sanity schema.
  • Description Quality: Clear manual testing steps for editors and frontend checks.

@vaibhav-cw

Copy link
Copy Markdown
Collaborator

@cw-pr-agent rereview

@mergemitra

mergemitra Bot commented Feb 2, 2026

Copy link
Copy Markdown

PR Scorecard

Score

Communication Quality Code Correctness & Design Quality Test Quality & Coverage Code Readability & Maintainability
Scoring Methodology

Communication Scoring Framework

The overall communication score is a weighted average:

Dimension Weight Evaluates
PR Description Quality 60% Title format (conventional commits) + Description clarity (what changed & why)
PR Size & Scope 25% Appropriate sizing, scope cohesion, and justification for size
Commit Messages 15% Conventional commits format, atomic & descriptive changes

Formula: (Description x 0.6) + (PR Size x 0.25) + (Commits x 0.15)

Code Scoring Framework

The scorecard evaluates code using 3 key reviewer questions:

Reviewer Question Category
Is this the right solution, implemented the right way? Code Correctness
Would this catch bugs if the code broke tomorrow? Test Quality
Can someone new understand and safely modify this in 6 months? Maintainability
PR Communication Notes

Description Quality

  • ✅ Manual testing steps remain detailed and reproducible for Studio + frontend flows
  • ❌ PR standards/testing/DoD checklists are still all unchecked; complete them or remove sections
  • ❌ Step 7 still mentions a JSON preview UI; ensure it exists or update steps to match current behavior

PR Size & Scope

  • ✅ This update is small (+10/-6) across 6 files and is quick to review
  • ✅ Delta stays focused on section rendering correctness and Next image config fixes

Commit Messages

  • ✅ New commit 'fix: address pr agent comments' follows conventional commits format
  • ❌ New commit message is vague; use specific summaries like 'fix(sections): use _key for section keys' going forward

Issue Notes

Code Correctness & Design Quality

  • 🟠 Unsafe component cast at components/PageRenderer.tsx:12 can still pair a section with the wrong component/props and hide runtime render errors when section types evolve
  • 🟠 [UNRESOLVED] Debug logging at app/[slug]/page.tsx:48 prints CMS content into server logs and can leak data/add noise in production
  • 🟠 [UNRESOLVED] suppressHydrationWarning at app/layout.tsx:29 masks real server/client mismatches, making hydration bugs harder to detect and potentially shipping broken UI states
  • 🟠 [UNRESOLVED] Using array index as React key at components/sections/FeatureListSection.tsx:10 can cause incorrect UI/state when features are reordered
  • 🟠 Removing SectionType export at components/sectionMap.ts:6 can break downstream imports at compile time if anything still references it

Test Quality & Coverage

  • 🟠 [UNRESOLVED] No automated tests for sections-based rendering/query at app/[slug]/page.tsx:43, components/PageRenderer.tsx:8 so GROQ/type regressions can ship unnoticed

Code Readability & Maintainability

  • 🟠 [UNRESOLVED] Missing explicit return types for exported components at app/[slug]/page.tsx:43, components/PageRenderer.tsx:8, components/sections/HeroSection.tsx:6 reduces TS enforcement and can hide invalid render paths
💬 Minor Issues (Nitpicks)

Code Correctness & Design Quality

  • 💬 console.warn at components/PageRenderer.tsx:15 will run on server/client for unknown section types and can spam logs in production; gate it to dev or add monitoring-only logging

Code Readability & Maintainability

  • 💬 React.ComponentType used without a type import at components/sectionMap.ts:6 relies on the global React namespace and may fail linting/type settings; prefer importing ComponentType from react

Based on 3908fc5...5dce4cc

Comment thread components/sectionMap.ts
import FeatureListSection from './sections/FeatureListSection'
import type { SectionProps } from './PageRenderer.type'

export const sectionMap: { [K in SectionProps['_type']]: React.ComponentType<Extract<SectionProps, { _type: K }>> } = {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

If other files still import SectionType, reintroduce it (or update all call sites) to avoid breaking the build.

export type SectionType = SectionProps['_type']

return (
<>
{sections.map((section) => {
const Component = sectionMap[section._type] as React.ComponentType<typeof section>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

Remove the React.ComponentType<typeof section> cast by narrowing on section._type (e.g., switch/if), so the compiler enforces that each section variant renders with the correct props.

switch (section._type) {
  case 'heroSection': return <HeroSection key={section._key} {...section} />
  ...
}

Comment thread components/sectionMap.ts
import FeatureListSection from './sections/FeatureListSection'
import type { SectionProps } from './PageRenderer.type'

export const sectionMap: { [K in SectionProps['_type']]: React.ComponentType<Extract<SectionProps, { _type: K }>> } = {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 💬 Minor [nitpick]

Prefer importing React types instead of relying on the global React namespace to avoid lint/typeconfig surprises.

import type { ComponentType } from 'react'
...
export const sectionMap: { ...: ComponentType<...> } = { ... }

@mergemitra

mergemitra Bot commented Feb 2, 2026

Copy link
Copy Markdown

PR Overview

PR Type: Feature

Focus Areas for Architect Review

  • Decide whether server-side debug logging (app/[slug]/page.tsx) and hydration warning suppression (app/layout.tsx) are acceptable in production, or enforce a “dev-only debugging” policy.
  • Define the long-term sections contract (GROQ projections must always include _type + _key + consistent image shapes) so the renderer stays type-safe as more section types are added.
  • Establish a minimal automated testing strategy for CMS-driven rendering (at least one test that validates the GROQ projection + a basic render path).
Rereview Impressions

Progress Since Last Review

  • Switched from index-based keys to stable Sanity _key in PageRenderer.
  • Strengthened sectionMap typing so _type maps to the correct component prop shape.
  • Added pathname: '/**' to next.config.ts remotePatterns (fixes Sanity image allowlisting).
  • Section prop types now include _key, aligning better with Sanity array items.

New Issues Introduced (if any)

  • SectionType export was removed from components/sectionMap.ts, which may break existing imports.

Remaining Concerns

  • PageRenderer still uses an unsafe component cast; consider narrowing on _type to keep rendering fully type-safe.
  • Previously flagged items (tests, debug logging, hydration suppression) appear unchanged and still worth addressing before merge.
PR Insights

Potential PR Improvements

  • Correctness: Avoid unsafe component casting; let TypeScript enforce prop matching.
  • Robustness: Gate console.warn to development to reduce production log noise.
  • Testing: Add automated tests for GROQ section shapes and rendering.
  • Best Practices: Import ComponentType explicitly instead of relying on global React.
  • Code Maintainability: Avoid breaking exports without migration notes or replacements.

PR Strengths

  • Code Maintainability: Uses stable _key for section rendering keys.
  • Correctness: Section prop types now include _key across all sections.
  • Best Practices: Strongly typed sectionMap improves component-to-type mapping safety.
  • Robustness: Unknown section types fail safely by returning null.
  • Correctness: Next image remotePatterns now allow Sanity paths via pathname.

@vaibhav-cw

Copy link
Copy Markdown
Collaborator

@cw-pr-agent rereview

@mergemitra

mergemitra Bot commented Feb 2, 2026

Copy link
Copy Markdown

PR Scorecard

Score

Communication Quality Code Correctness & Design Quality Test Quality & Coverage Code Readability & Maintainability
Scoring Methodology

Communication Scoring Framework

The overall communication score is a weighted average:

Dimension Weight Evaluates
PR Description Quality 60% Title format (conventional commits) + Description clarity (what changed & why)
PR Size & Scope 25% Appropriate sizing, scope cohesion, and justification for size
Commit Messages 15% Conventional commits format, atomic & descriptive changes

Formula: (Description x 0.6) + (PR Size x 0.25) + (Commits x 0.15)

Code Scoring Framework

The scorecard evaluates code using 3 key reviewer questions:

Reviewer Question Category
Is this the right solution, implemented the right way? Code Correctness
Would this catch bugs if the code broke tomorrow? Test Quality
Can someone new understand and safely modify this in 6 months? Maintainability
PR Communication Notes

Description Quality

  • ❌ No description updates since last review; PR standards/testing/DoD checklists remain unchecked
  • ❌ Step 7 still mentions a JSON preview UI, but current changes only add/remove console logs

PR Size & Scope

  • ✅ This update is small (+6/-5) across 5 files and remains focused on section rendering/query correctness
  • ❌ Reintroduced logging via components/PageRenderer.tsx; consider gating console.log to dev to avoid prod noise

Commit Messages

  • ✅ New commit 'fix: update qroq query to include unique key' follows conventional commits format
  • ❌ New commit 'fix: address unresolved comments' is vague; use specific summaries going forward

Issue Notes

Code Correctness & Design Quality

  • 🟠 catch { notFound() } at app/[slug]/page.tsx:50 turns unexpected fetch failures into 404s and silently hides real outages/auth issues, making debugging and monitoring harder
  • 🟠 [UNRESOLVED] Unsafe component cast at components/PageRenderer.tsx:12 can pair a section with the wrong component/props and hide runtime render errors when section types evolve
  • 🟠 Debug console.log at components/PageRenderer.tsx:13 can leak CMS structure into client/server logs and adds noise in production

Test Quality & Coverage

  • 🟠 [UNRESOLVED] No automated tests for sections-based GROQ projection + render path at app/[slug]/page.tsx:20, components/PageRenderer.tsx:10 means section shape regressions can ship unnoticed

Code Readability & Maintainability

  • 🟠 [UNRESOLVED] Exported component lacks an explicit return type at components/PageRenderer.tsx:10, reducing TS enforcement and allowing invalid render paths to slip through

Based on 5dce4cc...245d72a

<>
{sections.map((section) => {
const Component = sectionMap[section._type] as React.ComponentType<typeof section>
console.log('Rendering section:', section._type, 'with key:', section._key)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

Remove or gate this debug logging to development to avoid leaking CMS structure and spamming logs in production.

if (process.env.NODE_ENV === 'development') {
  console.log('Rendering section:', section._type, 'with key:', section._key)
}

return (
<>
{sections.map((section) => {
const Component = sectionMap[section._type] as React.ComponentType<typeof section>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Severity: 🟠 Major

Avoid as React.ComponentType<typeof section> by narrowing on section._type so TS enforces correct props per section variant.

switch (section._type) {
  case 'heroSection': return <HeroSection key={section._key} {...section} />
}

@mergemitra

mergemitra Bot commented Feb 2, 2026

Copy link
Copy Markdown

PR Overview

PR Type: Feature

Focus Areas for Architect Review

  • Decide the desired error-handling behavior for Sanity fetch failures (404 for missing slugs vs surfacing real fetch/auth/network errors as 500s) so outages aren’t masked.
  • Establish a minimal automated test strategy for CMS-driven sections (GROQ projection + basic render) to prevent regressions as new section types are added.
  • Confirm the long-term typing approach for sectionMap/renderer to avoid unsafe casts as the sections union grows.
Rereview Impressions

Progress Since Last Review

  • Removed server-side debug logging from the page fetch path.
  • Removed suppressHydrationWarning from the RootLayout body.
  • Added _key to GROQ projections and switched FeatureList rendering to stable _key keys.

New Issues Introduced (if any)

  • New console.log added in PageRenderer will run during rendering and can leak/spam logs if it ships.

Remaining Concerns

  • PageRenderer still relies on an unsafe component cast instead of _type-based narrowing.
  • Still no automated tests added for the new sections-driven query/render flow.
PR Insights

Potential PR Improvements

  • Robustness: Don't convert fetch failures into 404; surface real errors.
  • Correctness: Remove unsafe component casting; rely on section type narrowing.
  • Robustness: Gate console logging to development to avoid production leaks.
  • Code Maintainability: Add explicit return types for exported React components.
  • Testing: Add automated tests for GROQ projections and renderer mapping.

PR Strengths

  • Correctness: GROQ query now includes stable _key for sections.
  • Correctness: Feature items also fetch and use _key keys.
  • Robustness: Removed page fetch console logging from server route.
  • Robustness: Removed suppressHydrationWarning to expose real hydration mismatches.
  • PR Size: Changes are small and focused on section rendering safety.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants