北京
“兩個組件之間傳遞數據，不該是父子通信就行了嗎？”一位學習者在第7天的探索里，被一個問題困住了整個下午：注冊表單填好了，用戶卡片卻不自動出現。癥結在于，表單和卡片分屬兩個獨立的兄弟組件，它們之間的數據通路竟被框架的單向數據流堵死了。
項目結構很簡單：一個 App 父組件，底下掛著 Register（注冊表單）和 UserCard（用戶卡片）。他設想點擊按鈕后，卡片立刻感知新用戶并展示出來。可一試才發現，組件根本不允許相互“窺探”內部狀態。
他原先在 Register 里維護了一個 formData 狀態，提交后能更新本地數據，UserCard 卻一無所知。原因是狀態被封裝在組件內部，兄弟之間無法直接讀取，就像兩個室友各自鎖在屋里，門板沒有傳話孔。這個設計并非缺陷，而是單向數據流的基石——數據只能從父流向子，不存在橫向通道。
打破僵局的方法出奇簡單：把共享狀態“抬上去”。他不再將用戶數據放在 Register 內部，而是移到 App 父組件中。App 通過 useState 維護一個 users 數組，再將 users 和更新函數分別通過 props 下發給兩個子組件。于是 Register 提交時調用父組件提供的 onAddUser 函數，users 數組更新，框架自動觸發重渲染，UserCard 也就拿到了最新列表。這種模式在官方文檔里有個形象的名字——狀態提升。
把狀態上移至最近的共同父組件，相當于為兄弟搭建了一條經由“上級”的數據中繼。App 成為單一數據源，任何需要 users 數據的后代都從同一源頭讀取，自然不會出現不同步的問題。
這個過程也強化了另一個核心概念：“數據向下流動，事件向上傳遞”。Register 通過回調通知“有用戶注冊”，父組件接到信號后更新狀態，再自上而下把新數據注入 UserCard。
對這位學習者來說，狀態提升的意義遠不止解決一個小問題。他意識到，隨著應用變復雜，組件間數據依賴會盤根錯節，若不妥善管理共享狀態，代碼很快會變成亂麻。狀態提升提供了干凈、可預測的模式，迫使開發人員思考數據的真正歸屬，避免同一狀態在多處復制，從而減少維護中的詭異故障。
當天他還回顧了第6天的內容：利用 map() 從數據動態渲染多個組件、遵循不可變更新原則、使用可復用的 change handler 簡化表單，以及恪守 DRY 原則。這些心得恰好為狀態提升做了鋪墊——不可變更新確保 users 數組的變化能被察覺并觸發重渲染，而 DRY 自然導向了避免在兩個兄弟組件中各自維護一份用戶狀態的冗余做法。
當然，狀態提升并非萬能。當應用規模持續擴大，大量狀態集中在頂層組件時，props 層層傳遞就會變成“鉆孔”，可讀性反而下降。不過對于像他目前項目這樣的中等深度組件樹，狀態提升仍是最直接的方案。這位學習者坦言，通曉這一模式后，他對單向數據流有了更真切的體感，也愈發理解為什么許多成熟的狀態管理方案都在其基礎上構建。
他從當天的探索里提煉出一條實用經驗：一旦發現兩個組件需要共享同一份數據，而它們又非父子關系，先停下來想一想數據到底該歸誰所有。把它抬到共同祖先那里，用回調更新，再通過 props 分發給所有需要的后代。這個看似微小的思維轉變，足以讓一大類奇怪的 bug 消失于無形。第7天的學習，最終以一次小型架構升級收尾。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
