react中useState改變值不渲染

React中默認淺監聽，當State值為對象時，棧中存的是對象的引用（地址），setState改變的是堆中的數據

所以此時 setArr(arr) 后，棧中的地址還是原地址，React淺監聽到地址沒變，故會認為State并未改變，故沒有重渲染頁面

解決的辦法

示例如下：

利用ES6的拓展符

const [arr, setArr] = useState([])
setArr([...arr])

react踩坑 useState的兩次渲染

問題背景，函數組件中使用useState后，console.log發現組件重復渲染。

一開始我以為是useState的問題，經查驗，發現是index.tsx里<React.StrictMode>的坑

ReactDOM.render(
? <React.StrictMode>
? ? <App />
? </React.StrictMode>,
? document.getElementById('root')
);

以下內容，摘自react官網，如果你很忙可以不看！總之，渲染兩次沒事，生產模式下不會這樣。

StrictMode 目前有助于：

• 識別不安全的生命周期
• 關于使用過時字符串 ref API 的警告
• 關于使用廢棄的 findDOMNode 方法的警告

檢測意外的副作用

檢測過時的 context API

檢測意外的副作用

從概念上講，React 分兩個階段工作：

渲染 階段會確定需要進行哪些更改，比如 DOM。在此階段，React 調用 render，然后將結果與上次渲染的結果進行比較。

提交 階段發生在當 React 應用變化時。（對于 React DOM 來說，會發生在 React 插入，更新及刪除 DOM 節點的時候。）在此階段，React 還會調用 componentDidMount 和 componentDidUpdate 之類的生命周期方法。

提交階段通常會很快，但渲染過程可能很慢。因此，即將推出的 concurrent 模式 (默認情況下未啟用) 將渲染工作分解為多個部分，對任務進行暫停和恢復操作以避免阻塞瀏覽器。這意味著 React 可以在提交之前多次調用渲染階段生命周期的方法，或者在不提交的情況下調用它們（由于出現錯誤或更高優先級的任務使其中斷）。

渲染階段的生命周期包括以下 class 組件方法：

• constructor
• componentWillMount (or UNSAFE_componentWillMount)
• componentWillReceiveProps (or UNSAFE_componentWillReceiveProps)
• componentWillUpdate (or UNSAFE_componentWillUpdate)
• getDerivedStateFromProps
• shouldComponentUpdate
• render
• setState 更新函數（第一個參數）

因為上述方法可能會被多次調用，所以不要在它們內部編寫副作用相關的代碼，這點非常重要。忽略此規則可能會導致各種問題的產生，包括內存泄漏和或出現無效的應用程序狀態。不幸的是，這些問題很難被發現，因為它們通常具有非確定性。

嚴格模式不能自動檢測到你的副作用，但它可以幫助你發現它們，使它們更具確定性。

通過故意重復調用以下函數來實現的該操作：

• 類組件的 constructor，render 以及 shouldComponentUpdate 方法
• 類組件的生命周期方法 getDerivedStateFromProps
• 函數組件體
• 狀態更新函數 (即 setState 的第一個參數）
• 函數組件通過使用 useState，useMemo 或者 useReducer

注意：

這僅適用于開發模式。生產模式下生命周期不會被調用兩次。