Refactor component React với Claude Code một cách an toàn

Điều gì làm cho refactor React trở nên rủi ro trong code thực tế

Refactor React cảm thấy rủi ro vì hầu hết component không phải là các khối nhỏ, sạch sẽ. Chúng là đống sống gồm UI, state, effect, và những sửa chữa “chỉ thêm một prop nữa”. Khi bạn thay đổi cấu trúc, thường bạn vô tình thay đổi thời điểm chạy, identity, hoặc luồng dữ liệu.

Một refactor thường thay đổi hành vi khi nó vô tình:

• Reset state vì ranh giới component di chuyển hoặc key thay đổi.
• Thay đổi thời điểm effect chạy vì dependencies dịch chuyển hoặc mount/unmount khác.
• Làm hỏng memoization, khiến handlers và giá trị phái sinh đổi mỗi lần render.
• Dịch chuyển xử lý sự kiện (focus, blur, bàn phím, pointer), đặc biệt sau khi bọc hoặc tách markup.
• Nhân đôi fetch hoặc subscriptions vì logic bị sao chép thay vì được tập trung.

Refactor cũng biến thành rewrite khi “dọn dẹp” bị trộn lẫn với “cải tiến.” Bạn bắt đầu bằng việc trích một component, rồi đổi tên một đống thứ, rồi “chỉnh” shape của state, rồi thay hook. Sớm thôi bạn thay đổi logic trong khi cũng thay layout. Không có hàng rào bảo vệ, rất khó biết thay đổi nào gây ra bug.

Một refactor an toàn có một lời hứa đơn giản: người dùng nhận cùng hành vi, và bạn kết thúc với code rõ ràng hơn. Props, events, trạng thái loading, trạng thái lỗi và các trường hợp cạnh biên nên hoạt động như trước. Nếu hành vi thay đổi, nó phải có chủ đích, nhỏ, và được ghi rõ.

Nếu bạn refactor component React với Claude Code (hoặc bất kỳ trợ lý code nào), hãy coi nó như đồng lập trình nhanh, chứ không phải chế độ lái tự động. Yêu cầu nó mô tả các rủi ro trước khi sửa, đề xuất kế hoạch với các bước nhỏ an toàn, và giải thích cách nó kiểm tra rằng hành vi vẫn giữ nguyên. Rồi xác thực bằng chính bạn: chạy app, click những đường đi lạ, và dựa vào tests ghi lại những gì component đang làm hôm nay, không phải mong ước của bạn về nó.

Chọn mục tiêu và đặt mục tiêu refactor rõ ràng

Chọn một component mà thực sự đang tốn thời gian của bạn. Không phải toàn bộ trang, không phải “lớp UI,” và không phải một “dọn dẹp mơ hồ.” Chọn một component đơn lẻ khó đọc, khó sửa, hoặc đầy state và side effects mong manh. Mục tiêu hẹp cũng khiến đề xuất của trợ lý dễ xác minh hơn.

Viết một mục tiêu bạn có thể kiểm tra trong năm phút. Mục tiêu tốt nói về cấu trúc, không phải kết quả: “tách thành các component nhỏ hơn,” “làm cho state dễ theo dõi hơn,” hoặc “làm cho testable mà không phải mock nửa app.” Tránh mục tiêu như “làm tốt hơn” hoặc “tăng hiệu năng” trừ khi bạn có metric và nút thắt rõ ràng.

Đặt ranh giới trước khi mở editor. Những refactor an toàn thường nhàm chán:

• Không thay đổi giao diện (cùng layout, cùng văn bản, cùng spacing).
• Không tính năng mới (ngay cả “nhân tiện thêm sort”).
• Cùng hành vi bên ngoài (props vào, UI và callbacks ra như trước).
• Một component mỗi lần (hoàn thành cái này trước khi bắt đầu cái khác).

Rồi liệt kê các phụ thuộc có thể âm thầm phá vỡ hành vi khi bạn di chuyển code: API calls, context providers, routing params, feature flags, analytics events, và trạng thái global chia sẻ.

Ví dụ cụ thể: bạn có OrdersTable 600 dòng fetch data, filter, quản lý selection, và show drawer với chi tiết. Mục tiêu rõ ràng có thể là: “tách việc render row và drawer UI thành component, và đưa selection state vào một reducer, không thay đổi UI.” Mục tiêu đó cho bạn biết “xong” là gì và thứ gì nằm ngoài phạm vi.

Đóng băng hành vi trước khi chạm vào code

Trước khi refactor, hãy coi component như một hộp đen. Nhiệm vụ của bạn là ghi lại nó đang làm gì hôm nay, không phải bạn muốn nó làm gì. Điều này giữ cho refactor không biến thành redesign.

Bắt đầu bằng cách viết hành vi hiện tại bằng ngôn ngữ đơn giản: với các input này, UI hiển thị output kia. Bao gồm props, URL params, feature flags, và bất kỳ dữ liệu nào lấy từ context hoặc store. Nếu dùng Claude Code, dán một đoạn nhỏ, tập trung và yêu cầu nó diễn lại hành vi thành các câu chính xác bạn có thể kiểm tra sau.

Bao phủ các trạng thái UI mà người dùng thực sự thấy. Một component có thể trông ổn trên happy path trong khi phá khi vào loading, empty, hoặc error.

Cũng ghi lại các quy tắc ngầm mà dễ bỏ sót và thường khiến refactor phá hành vi:

• Lựa chọn mặc định (tab được chọn, cột sort mặc định, giá trị filter ban đầu).
• Quy tắc định dạng (ngày, tiền tệ, truncate, viết hoa).
• Quy tắc sắp xếp (sort ổn định, nhóm, pinned items).
• Quy tắc tương tác (cái gì reset khi đổi filter, cái gì giữ focus).
• Các trường hợp cạnh mà người dùng dựa vào (chuỗi rỗng vs null, giá trị 0, dữ liệu không đầy đủ).

Ví dụ: bạn có bảng user load results, hỗ trợ tìm kiếm, và sort theo “Last active.” Viết lại điều gì xảy ra khi search rỗng, khi API trả về danh sách rỗng, khi API lỗi, và khi hai user có cùng giá trị “Last active”. Ghi chi tiết nhỏ như sort có phân biệt chữ hoa/thường không, và bảng có giữ trang hiện tại khi filter thay đổi không.

Khi ghi chú của bạn trở nên nhàm chán và cụ thể, bạn đã sẵn sàng.

Thêm characterization tests để khoá hành vi hiện tại

Characterization tests là các test “đây là những gì nó làm hôm nay”. Chúng mô tả hành vi hiện tại, ngay cả khi nó kỳ quặc, không nhất quán, hoặc rõ ràng không phải điều bạn muốn về lâu dài. Nghe có vẻ ngược, nhưng điều này ngăn refactor lặng lẽ biến thành rewrite.

Khi refactor component React với Claude Code, những test này là lan can an toàn. Công cụ có thể giúp thay đổi cấu trúc, nhưng bạn quyết định những gì không được thay đổi.

Tập trung vào những gì người dùng (và code khác) phụ thuộc vào:

• Rendering: gì xuất hiện cho các trạng thái chính (empty, loading, error, normal).
• Interactions: click, nhập, điều hướng bàn phím, chọn, phân trang.
• Giá trị phái sinh: tổng, số lượng lọc, quy tắc định dạng, trạng thái disabled.
• Side effects: cuộc gọi analytics, lưu nháp, cập nhật URL, quản lý focus.
• Xử lý lỗi: chuyện gì xảy ra khi một hành động thất bại.

Để giữ test ổn định, assert kết quả, không phải implementation. Ưu tiên “nút Save bị disabled và xuất hiện thông báo” hơn “setState đã được gọi” hay “hook này chạy”. Nếu test vỡ vì bạn đổi tên component hoặc sắp xếp hooks, tức là nó không bảo vệ hành vi.

Hành vi bất đồng bộ là nơi refactor thường thay đổi timing. Xử lý rõ ràng: chờ UI ổn định rồi assert. Nếu có timers (debounced search, toast delayed), dùng fake timers và tiến thời gian. Nếu có network calls, mock fetch và assert những gì người dùng thấy sau success và failure. Với các luồng giống Suspense, test cả fallback lẫn view sau khi resolve.

Ví dụ: bảng “Users” chỉ hiện “No results” sau khi search hoàn thành. Một characterization test nên khoá chuỗi đó: loading indicator trước, rồi rows hoặc empty, bất kể bạn tách component thế nào sau này.

Phương pháp từng bước thực tế với Claude Code

Thắng lợi không phải là “thay đổi lớn nhanh hơn.” Thắng lợi là có bức tranh rõ ràng component đang làm gì, rồi thay đổi một việc nhỏ tại một thời điểm trong khi giữ hành vi ổn định.

Bắt đầu bằng việc dán component và yêu cầu tóm tắt trách nhiệm bằng tiếng thường. Khuyến khích cụ thể: nó hiển thị dữ liệu gì, xử lý hành động người dùng nào, và kích hoạt side effects nào (fetching, timers, subscriptions, analytics). Điều này thường lộ ra các việc ẩn khiến refactor rủi ro.

Tiếp theo, yêu cầu bản đồ phụ thuộc. Bạn cần danh mục mọi input và output: props, đọc context, custom hooks, local state, giá trị phái sinh, effects, và helper ở module-level. Bản đồ hữu ích cũng chỉ ra cái nào an toàn để di chuyển (pure calculations) và cái nào “dính” (timing, DOM, network).

Rồi yêu cầu nó đề xuất các candidate để tách, với một quy tắc nghiêm ngặt: tách phần view thuần túy ra khỏi phần controller có state. Các đoạn JSX-heavy chỉ cần props là ứng viên xuất sắc để trích. Phần trộn event handlers, async calls và cập nhật state thường không nên tách ngay.

Một workflow bền trong code thực tế:

• Xác nhận bản tóm tắt trách nhiệm và bản đồ phụ thuộc khớp với những gì bạn thấy.
• Chọn một candidate trích là presentation thuần túy, và chỉ di chuyển phần đó.
• Chạy lại characterization tests và làm click-through thủ công nhanh.
• Giải quyết một rối state/effect tiếp theo (không phải tất cả), rồi test lại.
• Lặp cho đến khi component gốc đọc như một coordinator nhỏ.

Các mốc kiểm tra là quan trọng. Yêu cầu Claude Code một kế hoạch tối thiểu nơi mỗi bước có thể commit và revert. Một mốc thực tế có thể là: “Trích \u003cTableHeader\u003e mà không thay đổi logic” trước khi đụng tới sorting state.

Ví dụ cụ thể: nếu component render customer table, điều khiển filters, và fetch data, hãy trích table markup trước (headers, rows, empty state) thành component thuần. Chỉ sau đó mới di chuyển filter state hoặc fetch effect. Trật tự này giữ bugs không bay theo JSX.

Tách component mà không di chuyển bug

Khi tách một component lớn, rủi ro không phải là di chuyển JSX. Rủi ro là vô tình thay đổi luồng dữ liệu, timing, hoặc wiring sự kiện. Xử lý extraction như công việc copy-and-wire trước, rồi cleanup sau.

Bắt đầu bằng cách tìm ranh giới đã tồn tại trong UI, không phải trong cấu trúc file. Tìm phần bạn có thể mô tả như một “thứ” riêng: header với actions, filter bar, results list, footer với pagination.

Một bước đầu an toàn là tách presentational components thuần: props in, JSX out. Giữ chúng nhàm chán có chủ ý. Không state mới, không effect mới, không API call mới. Nếu component gốc có handler click làm ba việc, giữ handler ở parent và truyền xuống.

Ranh giới an toàn thường gồm header, list và row item, filters (chỉ inputs), footer controls (pagination, totals, bulk actions), và dialogs (mở/đóng và callbacks truyền vào).

Đặt tên quan trọng hơn bạn nghĩ. Chọn tên cụ thể như UsersTableHeader hoặc InvoiceRowActions. Tránh tên chung chung như “Utils” hay “HelperComponent” vì chúng che giấu trách nhiệm và mời gọi trộn concerns.

Chỉ giới thiệu container component khi có nhu cầu thực sự: một khối UI phải sở hữu state hoặc effects để giữ tính mạch lạc. Ngay cả khi thế, giữ nó hẹp: một container tốt chỉ sở hữu một mục đích (ví dụ “filter state”) và truyền mọi thứ khác như props.

Gỡ rối state và effects bằng các bước nhỏ, an toàn

Các component lộn xộn thường trộn ba loại dữ liệu: UI state thật sự (những gì người dùng thay đổi), dữ liệu suy diễn (có thể tính), và server state (từ mạng). Nếu bạn coi tất cả là local state, refactor sẽ rủi ro vì bạn có thể vô tình thay đổi thời điểm cập nhật.

Bắt đầu bằng cách gắn nhãn từng mẩu dữ liệu. Hỏi: người dùng có chỉnh cái này không, hay tôi có thể tính từ props, state và fetched data? Hỏi tiếp: giá trị này có được sở hữu ở đây không, hay chỉ được truyền qua?

Tách state khỏi giá trị suy diễn

Giá trị suy diễn không nên nằm trong useState. Di chuyển chúng vào hàm nhỏ, hoặc selector có memo khi tốn kém. Điều này giảm cập nhật state và làm hành vi dễ dự đoán hơn.

Một pattern an toàn:

• Chỉ giữ những giá trị người dùng chỉnh trong useState.
• Tính các giá trị chỉ để hiển thị từ những inputs đó.
• Truyền các giá trị tính được xuống, không truyền setters, trừ khi child thực sự chỉnh chúng.
• Nếu performance quan trọng, bọc tính toán nặng bằng useMemo.

Làm cho effects trở nên nhàm chán và cụ thể

Effects phá vỡ hành vi khi chúng làm quá nhiều hoặc phản ứng với dependencies sai. Hướng tới một effect cho một mục đích: một effect để sync lên localStorage, một effect để fetch, một effect để subscribe. Nếu một effect đọc nhiều giá trị, thường nó đang ẩn trách nhiệm thừa.

Nếu dùng Claude Code, yêu cầu một thay đổi nhỏ: tách một effect thành hai, hoặc chuyển một trách nhiệm vào helper. Rồi chạy characterization tests sau mỗi di chuyển.

Cẩn thận với prop drilling. Thay bằng context chỉ có ích khi nó loại bỏ wiring lặp lại và làm rõ ownership. Một dấu hiệu tốt là context đọc như khái niệm cấp ứng dụng (current user, theme, feature flags), không phải là thủ thuật cho một cây component.

Ví dụ: một bảng có thể lưu cả rows và filteredRows trong state. Giữ rows là state, tính filteredRows từ rows cộng query, và giữ code lọc trong hàm thuần để dễ test và khó phá.

Dùng checkpoints để revert nhanh

Refactor thất bại thường khi bạn thay quá nhiều trước khi nhận ra. Cách sửa đơn giản: làm việc theo checkpoints nhỏ, và coi mỗi checkpoint như một release mini. Dù bạn làm trong một branch, giữ thay đổi ở cỡ PR để bạn thấy gì hỏng và vì sao.

Sau mỗi bước ý nghĩa (tách component, thay đổi luồng state), dừng lại và chứng minh bạn không đổi hành vi. Bằng chứng có thể tự động (tests) và thủ công (kiểm tra nhanh trong trình duyệt). Mục tiêu không phải hoàn hảo. Mà là phát hiện nhanh.

Một vòng checkpoint thực tế:

• Thực hiện một thay đổi nhỏ (một extraction, một di chuyển state, một dọn effect).
• Chạy full test suite, hoặc ít nhất các characterization tests cho vùng đó.
• Kiểm tra thủ công nhanh các đường chính bạn quan tâm.
• Lưu điểm rollback (git commit, hoặc snapshot nền tảng nếu có).

Nếu dùng nền tảng như Koder.ai, snapshots và rollback có thể như lan can an toàn khi bạn lặp. Bạn vẫn muốn commits bình thường, nhưng snapshots giúp khi cần so sánh phiên bản “known good” với hiện tại, hoặc khi một thử nghiệm đi lệch.

Giữ một sổ tay hành vi đơn giản trong khi làm. Nó chỉ là ghi chú ngắn những gì bạn đã kiểm tra, và ngăn bạn kiểm tra lại cùng thứ nhiều lần.

Ví dụ:

• Table sorting: vẫn sort theo cùng cột và giữ trạng thái mũi tên.
• Row selection: số lượng chọn cập nhật, bulk actions bật đúng.
• Loading và error states: spinner và nút retry xuất hiện trong cùng các trường hợp.

Khi có lỗi, sổ tay cho bạn biết phải kiểm tra lại gì, và các checkpoint làm việc revert rẻ tiền.

Bẫy thường gặp làm hỏng hành vi trong refactor

Hầu hết refactor thất bại theo những cách nhỏ, nhàm chán. UI vẫn hoạt động, nhưng một quy tắc spacing biến mất, một handler click chạy hai lần, hoặc một list mất focus khi gõ. Trợ lý có thể làm tệ hơn vì code trông sạch hơn ngay cả khi hành vi trôi dạt.

Một nguyên nhân phổ biến là thay đổi cấu trúc. Bạn tách component rồi bọc thêm một \u003cdiv\u003e, hoặc đổi một \u003cbutton\u003e thành \u003cdiv\u003e có thể click được. CSS selectors, layout, keyboard navigation, và test queries có thể đổi mà không ai để ý.

Các bẫy thường làm hỏng hành vi:

• DOM thay đổi trông vô hại: wrappers thừa, loại element khác, hoặc attributes bị di chuyển có thể phá CSS và tests. Giữ cùng tags và data attributes cho tới khi bạn muốn thay.
• Vô tình phá equality referential: tạo object/function mới inline ({} hoặc () => {}) có thể kích hoạt render thêm và reset state con. Chú ý các props từng ổn định.
• Sai dependencies của hook: chuyển logic vào useEffect, useMemo, useCallback có thể tạo stale values hoặc vòng lặp nếu dependencies sai. Nếu effect trước kia chạy “on click”, đừng biến nó thành cái chạy “khi bất cứ thứ gì thay đổi”.
• Nâng cấp hành vi không được phép: “fix” edge cases, thay quy tắc sort, hay cải thiện validation là thay đổi sản phẩm. Khớp hành vi hiện tại trước, dù nó lạ.

Ví dụ: tách bảng và đổi keys hàng từ ID sang index mảng có thể trông ổn, nhưng phá selection khi hàng reorder. Xem “sạch” là phần thưởng. Xem “cùng hành vi” là yêu cầu.

Checklist nhanh trước khi kết thúc

Trước khi merge, bạn cần bằng chứng rằng refactor giữ hành vi. Tín hiệu dễ nhất là nhàm chán: mọi thứ vẫn hoạt động mà bạn không phải “sửa” tests.

Chạy kiểm tra nhanh sau thay đổi cuối:

• Tests cũ pass mà không chỉnh, và characterization tests mới pass (không snapshot bị cập nhật, không assertion bị đổi).
• UI vẫn có cùng trạng thái hiện thị: loading, empty, error, success, và xuất hiện trong cùng điều kiện.
• Props công khai và contracts callback giữ nguyên: cùng tên, cùng shape đối số, cùng thời điểm (ví dụ onChange vẫn kích hoạt khi người dùng nhập, không khi mount).
• Focus và hành vi bàn phím vẫn giống: tab order, Enter/Escape, và nơi focus nằm sau hành động như save, close, hoặc pagination.
• Analytics và side effects vẫn xảy ra một lần, vào cùng thời điểm như trước (ví dụ một event “Viewed” mỗi lần load màn hình, không mỗi render).

Kiểm tra nhanh: mở component và làm một luồng kỳ quặc, như kích hoạt lỗi, retry, rồi clear filters. Refactor thường phá transitions ngay cả khi đường chính vẫn hoạt động.

Nếu bất kỳ mục nào fail, revert thay đổi cuối và làm lại bằng bước nhỏ hơn. Thường nhanh hơn là debug một diff lớn.

Ví dụ thực tế: tách một table component lộn xộn

Hãy tưởng tượng ProductTable làm mọi việc: fetch data, quản lý filters, điều khiển pagination, mở confirm dialog để xóa, và xử lý actions hàng như edit, duplicate, archive. Ban đầu nhỏ, nó lớn lên thành file 900 dòng.

Triệu chứng quen thuộc: state rải rác trong nhiều useState, một vài useEffect chạy theo thứ tự cụ thể, và một thay đổi “vô hại” phá pagination chỉ khi filter đang active. Mọi người ngại chạm vì nó unpredictable.

Trước khi thay cấu trúc, khoá hành vi bằng vài characterization tests. Tập trung vào thao tác người dùng, không phải state nội bộ:

• Apply filter cập nhật rows hiển thị và reset về page 1.
• Pagination giữ filter và hiển thị đúng số trang.
• Click “Archive” disable hàng trong khi request đang diễn ra.
• Empty state hiển thị khi không có kết quả phù hợp filter.
• Loading state không nháy “No results.”

Giờ bạn có thể refactor theo các commit nhỏ. Kế hoạch extraction sạch có thể là: FilterBar render controls và emit filter changes; TableView render rows và pagination; RowActions sở hữu menu action và UI confirm dialog; useProductTable hook giữ logic rối (query params, derived state, side effects).

Thứ tự quan trọng. Tách UI ngu trước (TableView, FilterBar) bằng cách truyền props qua nguyên vẹn. Để phần rủi ro lại sau cùng: di chuyển state và effects vào useProductTable. Khi làm, giữ tên prop và shape event cũ để tests tiếp tục pass. Nếu test vỡ, bạn đã tìm thấy thay đổi hành vi, không phải vấn đề style.

Bước tiếp theo: làm cho phương pháp này lặp lại được

Nếu bạn muốn refactor React components với Claude Code an toàn mỗi lần, biến những gì bạn vừa làm thành template nhỏ có thể tái sử dụng. Mục tiêu không phải thêm process. Mà là giảm bất ngờ.

Giữ một template refactor đơn giản

Viết playbook ngắn bạn có thể theo cho bất kỳ component nào, ngay cả khi mệt hoặc vội:

• Ghi mục tiêu trong một câu (cải thiện gì, không được làm gì).
• Khoá hành vi hiện tại bằng characterization tests (bao gồm các edge case lạ).
• Làm một thay đổi nhỏ (extract, rename, move state, isolate effects).
• Chạy tests và check nhanh UI.
• Lưu checkpoint để revert nếu cần.

Lưu đoạn này làm snippet trong notes hoặc repo để refactor tiếp theo bắt đầu với cùng lan can an toàn.

Quyết định làm gì sau khi hành vi bị khoá

Khi component ổn định và dễ đọc hơn, chọn bước tiếp theo dựa trên ảnh hưởng tới người dùng. Thứ tự phổ biến: accessibility trước (labels, focus, keyboard), rồi performance (memoization, render đắt), rồi dọn dẹp (types, tên, mã chết). Đừng trộn cả ba trong một PR.

Nếu bạn dùng workflow kiểu vibe-coding như Koder.ai (koder.ai), planning mode giúp bạn phác thảo bước trước khi chạm code, snapshots và rollback làm checkpoint khi lặp. Khi xong, export source giúp review diff và giữ lịch sử sạch.

Biết khi nào dừng và ship

Dừng refactor khi tests bao phủ hành vi bạn sợ phá, thay đổi tiếp theo là tính năng mới, hoặc bạn có ham muốn “hoàn hảo hóa.” Nếu tách một form lớn gỡ rối state và tests cover validation + submit, ship nó. Lưu các ý tưởng còn lại thành backlog ngắn cho sau.