TechnicalCollectible prompt

Split a giant component into smaller ones safely

Break a huge file into focused components and hooks in small steps, with behavior unchanged after each.

Claude CodeCursorWindsurf

Curated by Nvoka

Nvoka wordmark logo
Nvoka wordmark logoTechnical

Split a giant component into smaller ones safely

Act as a senior React engineer. {{page_or_feature}} in my {{tech_stack}} project lives in one huge component, hundreds of lines long, and every AI edit to it breaks something. Split it into smaller pieces without changing anything users see or do. 1. Read it and map its jobs: data fetching, state, derived values, event handlers, side effects, and each visual section. Show the map as a short list with line ranges before touching anything. 2. Lock behavior first. If there are no tests, add a few that render it with realistic data and cover the main interactions plus the loading, empty and error states. Take screenshots at 360 and 1280px to compare later. 3. Extract in this order, one step per commit, running the tests after each: - Pure helpers and formatting functions, into their own file - Visual sections, into components that take props and hold no data logic - Related state and effects, into a custom hook with a clear name and return value - Leave the parent as a short coordinator that reads like a table of contents 4. Rules while splitting: - Move code, don't rewrite it. No renaming, restyling or bug fixing in the same step; note bugs for later - Keep state as close as possible to where it's used, and lift it only when two pieces need it - If props pass through more than two levels, stop and suggest a better boundary instead of adding a global store - Reuse existing project components rather than creating near-duplicates - Keep accessibility attributes, keys and test ids exactly as they are 5. At the end, compare the screenshots and rerun all tests. Report the new file structure, one line on what each file does, and the bugs you noticed but didn't fix.
Technicalnvoka.com/library/nvoka-split-a-giant-component-into-smaller-ones-safelyScan to open
Technical

Split a giant component into smaller ones safely

Break a huge file into focused components and hooks in small steps, with behavior unchanged after each.

Nvoka logo

Curated by Nvoka

Claude CodeCursorWindsurfCodex
Add to my library

Make it yours

Fill in the blanks and change any word. Only your copy changes, never the card.

Fill in the blanks

0 of 2 filled

Your prompt

Act as a senior React engineer. {{page_or_feature}} in my {{tech_stack}} project lives in one huge component, hundreds of lines long, and every AI edit to it breaks something. Split it into smaller pieces without changing anything users see or do. 1. Read it and map its jobs: data fetching, state, derived values, event handlers, side effects, and each visual section. Show the map as a short list with line ranges before touching anything. 2. Lock behavior first. If there are no tests, add a few that render it with realistic data and cover the main interactions plus the loading, empty and error states. Take screenshots at 360 and 1280px to compare later. 3. Extract in this order, one step per commit, running the tests after each: - Pure helpers and formatting functions, into their own file - Visual sections, into components that take props and hold no data logic - Related state and effects, into a custom hook with a clear name and return value - Leave the parent as a short coordinator that reads like a table of contents 4. Rules while splitting: - Move code, don't rewrite it. No renaming, restyling or bug fixing in the same step; note bugs for later - Keep state as close as possible to where it's used, and lift it only when two pieces need it - If props pass through more than two levels, stop and suggest a better boundary instead of adding a global store - Reuse existing project components rather than creating near-duplicates - Keep accessibility attributes, keys and test ids exactly as they are 5. At the end, compare the screenshots and rerun all tests. Report the new file structure, one line on what each file does, and the bugs you noticed but didn't fix.
See all