一些關於react的keep-alive功能相關知識在這裡(下)
本篇承接上篇內部, 所以是從第九點開始
九、保留頁面scroll
比如頁面上的table裡有100條資料, 我們想看第100條資料, 那就要滾動不少距離, 不少場景這種滾動距離也是有必要保留的。
這裡使用的方法其實比較傳統啦, 首先在KeepAliveProvider 下發一個處理滾動的方法:
const handleScroll = useCallback(
(cacheId, event) => {
if (catheStates?.[cacheId]) {
const target = event.target
const scrolls = catheStates[cacheId].scrolls
scrolls[target] = target.scrollTop
}
},
[catheStates]
) 在Keeper元件裡面接收並執行:
const { dispatch, mount, handleScroll } = useContext(CacheContext)
useEffect(() => {
const onScroll = handleScroll.bind(null, cacheId)
(divRef?.current as any)?.addEventListener?.('scroll', onScroll, true)
return (divRef?.current as any)?.addEventListener?.('scroll', onScroll, true)
}, [handleScroll])在Keeper裡面將滾動屬性賦予元素:
useEffect(() => {
const catheState = catheStates[cacheId]
if (catheState && catheState.doms) {
const doms = catheState.doms
doms.forEach((dom: any) => {
(divRef?.current as any)?.appendChild?.(dom)
})
// 新增
doms.forEach((dom: any) => {
if (catheState.scrolls[dom]) {
dom.scrollTop = catheState.scrolls[dom]
}
})
} else {
mount({
cacheId,
reactElement: props.children
})
}
}, [catheStates]) 這裡如果不主動增加賦予scroll的方法的話, 滾動距離是不會被儲存的, 因為Keeper每次都是新的。
十、KeepAliveProvider內部 Keeper子元件內部的CacheContext
我們是把元件渲染在 KeepAliveProvider 裡面, 那麼如果某個Provider是在 KeepAliveProvider 內部定義的, 則KeepAliveProvider級別的元件是無法使用 Consumer 拿到這個值的。
這裡就引出一個問題, 如何將 KeepAliveProvider 中的元件的上下文, 修改為Keeper元件的上下文。
這裡演示一下最直接的方式, 讓使用者傳入Provider與其value值。
<Keeper
cacheId="home"
context={{ Provider: Provider, value: value }}>
<Home />
</Keeper> 我們拿到這兩個值後直接在Keeper中修改reactElement的結構:
mount({
cacheId,
reactElement: context ?
<context.Provider
value={context.value}>{props.children}</context.Provider> :
props.children
}) 當檢測到context有值則直接在 props.children 外面套一層, 當然這裡存在一個多層Provider巢狀的問題沒有去解決, 因為逐漸複雜起來它的實用性已經在下降了, 接下來還有新的bug來襲。
十一、需要傳值的元件
大家有沒有發現上述元件所有邏輯, 都是直接寫在Keeper標籤裡面的, 並沒有任何的傳值, 但是比較常見的一種場景是下面這樣的:
function Root (){
const [n, setN] = useState(1)
return
(
<>
<button onClick={()=>setN(n+1)}>n+1</button>
<Keeper>
<Home n={n} />
</Keeper>
</>
)
} 這個n是Keeper外層傳遞給Home元件的, 這種寫法下會導致n雖然變化了但是Home裡面不會響應。
這個bug我是這樣發現的, 當我把這個外掛用在我們團隊的專案裡的一個表格為主的頁面時 , table一直顯示是空的, 並且輸入框也無法輸入值, 經過測試發現其實值是有變化的, 只是沒有展示在元件的dom上。
嘗試了好久後試了下react-activation 很遺憾它也有相同的問題, 那其實就說明這個bug很可能無法解決或者就是這個外掛本身的架構存在的問題。
十二、為何這麼奇怪的bug場景
當時這個bug折磨了我一天半的時間, 最後定位到外界的傳參已經不能算是這個元件本身的引數了, 我們元件的實際渲染位置是 KeepAliveProvider 的第一層, 而Keeper的外層還在KeepAliveProvider的更內層, 這就導致這些值的變化其實是沒有能夠影響到元件。
可以理解為這些值的變化, 比如n的變化就如同window.n的改變一樣, react元件是不會去響應這個變化的。
那其實我們要做的就是讓外層傳入的值的變化, 可以帶動元件的樣式變化 (逐漸入坑!)。
十三、將props單獨拿出來
我借鑑了網上另一種keep-alive元件的寫法, 把Keeper元件改為一個keeper的方法, 這個方法返回一個元件看, 這樣就可以接收一個props了, 也就把變數圈定在props這個範圍:
const Home = keeper(HomePage, { cacheId: 'home' })
function Root(){
const [n, setN] = useState(1)
return (
<>
<button onClick={()=>setN(n+1)}>n+1</button>
<Home n={n}> // 此處可以傳值了
</>
)
} 這樣做的目的是讓開發者把能夠影響元件狀態的引數一口氣傳進來, 比如之前一個Keeper裡面可以有多個元件, 這種情況就不好控制哪些引數變化會導致哪些元件更新, 但以元件的方式可以明顯得知元件接收到的props裡面的值的改變會導致元件更新。
我想到的方案是, 在KeepAliveProvider裡面新建propsObj, 用來專門儲存每個快取元件的props, 之所以如此設計將其單獨拿出來, 是要把傳參與元件的邏輯拆分開, 不少邏輯會監控catheStates的變化而執行, 但是props的變化沒有必要觸發這些。
const [propsObj, setPropsObj] = useState<any>();
return (
<CacheContext.Provider value={{ setPropsObj, propsObj }}>
{props.children}
//.... 略
KeepAliveProvider 裡面的渲染需要變一個形式, reactElement 變成元件了, 別忘了名字要變成大寫的。
// 舊的
// {reactElement}
// 新的
{propsObj &&
<ReactElement {...propsObj[cacheId]}></ReactElement>} 改裝一下Keeper檔案, 首先要把檔名改為 keeper, 匯出的方法要進行一下更改。
export default function (
RealComponent: React.FunctionComponent<any>, { cacheId = '' }) {
return function Keeper(props: any) {
// ... 略 Keeper內mount方法的使用也稍作調整:
mount({
cacheId,
ReactElement: RealComponent
}) 關鍵的來了, 我們要在Keeper裡面監測props的變化, 來更新propsObj:
const { propsObj, setPropsObj } = useContext(CacheContext)
useEffect(() => {
setPropsObj({
...propsObj,
[cacheId]: props
})
}, [props])
十四、快取失效的bug
上述我們已經把外掛改裝了形式, 並且發現可以讓如下場景正常渲染, Home元件的props是外界傳入的:
const Home = keeper(HomePage, { cacheId: 'home' })
const RootComponent: React.FC = () => {
return (
<KeepAliveProvider>
<Router>
<Routes>
<Route path={'/'} element={<Mid />} />
</Routes>
</Router>
</KeepAliveProvider>
)
}
function Mid() {
const [n, setN] = useState(1)
return (
<div>
<button onClick={() => setN(n + 1)}>n+1</button>
<Home n={n}></Home>
</div>
)
}
function HomePage(props: { n: number }) {
return <div>home {props.n}</div>
} 但是此時如果切換頁面後再返回home頁面, home頁面的快取是會失效的。
其實是因為我們實時監控props的變化, 下次重新渲染時會導致props變化, 然後值就會被初始化了, 導致元件也恢復到了早期的配置, 可是.... 這不就是快取失敗了嗎?
每次元件props被重置就會導致元件的相關資料被重置, 嘗試把home元件做如下更改:
function HomePage(props: { n: number }) {
const [x, setX] = useState(1)
return (
<div>
<button onClick={() => setX(x + 1)}>x + 1</button>
<div>home {props.n}</div>
<div>home: x {x}</div>
</div>
)
}
上述寫法會導致每次啟用home元件, 只能保留x的值, n的值會與傳入的相同。
這種變化可能會導致bug, 假設只有 n > 2 才能讓 x > 3, 此時我們通過點選事件讓 n = 5 , x = 4了, 此時切換到其他頁面再回來, 就變成了n = 1, x=4, 違背了我們的初始限制條件, 以此類推在真實複雜的開發環境中此現象會導致各種奇怪的問題。
十五、認知的代價
上面的場景可以通過開發人員自己來控制, 理想情況是keep-alive外掛只用來處理不需要外界傳參, 以及不會被外界引數的變化影響的元件, 但這就開始麻煩了。
這類問題導致開發者在外掛身上要花的學習成本提高, 使用成本提高, 並且如果某個元件本來不需要傳參, 我們用keep-alive包裹起來了, 後續又需要傳參了, 改變的成本想想都麻煩。
網上現有(2022年04月10日17:16:22)元件的官網基本是沒有認真的對使用者講述相關的問題, 往往都是以介紹"使用方法"與闡述自己的優勢為主, 這就導致使用者被莫名其妙的bug折磨。
傳遞 Provider 的方法也有問題, 需要傳遞可能不是本頁程式碼的Provider, 難受的了啊。
想要解決keep-alive相關問題的思路可以換一下, 最好是在react原始碼裡支援一波, 比如可以指定某些元件不被銷燬, 其實我們可以關注一下react18的後續版本, 現在這個時間段react18釋出了正式版。
十六、如何升級到react18
方式一: create-react-app 建立新專案
現階段直接使用下面的命令, 就可建立react18專案:
npx create-react-app my_react
下面這種使用 --template 指定模板的還不行, 因為模板程式碼還沒更新:
npx create-react-app my_react --template typescript這裡可以檢視所有react專案的模板 create-react-app專案可指定的模板。
方式二: 老專案改裝
首先直接把依賴裡面的react 與 react-dom的版本號改成 "^18.0.0"即可。
兩種方式都需要修改 index.js
啟動專案會有報錯資訊:
舊版的index.js
新版的index.js
其他的沒有太多更改了。
十七、react18 Offscreen 元件的用法
Offscreen 允許 React 通過隱藏元件而不是解除安裝元件來保持這樣的狀態, React 將呼叫與解除安裝時相同的生命週期鉤子, 但它也會保留 React 元件和 DOM 元素的狀態。
React Activation 中也推薦大家關注這個屬性:
Offscreen 是什麼的官方說法可以看這篇文章裡的翻譯: React v18.0新特性官方文件[中英文對照
Offscreen的測試用例:
遺憾的是 Offscreen 元件並沒有在當前版本推出, 其還處於不穩定階段, 但我們可以通過 react18 裡面的測試用例來預覽一下其用法:
通過上述寫法還無法看出 Offscreen 到底如何使用, 只知道它可能是以元件的形式出現, 並且需要傳入一個mode屬性, 更多用法期待官方儘快推出吧。
end
讓我們一起期待 react18 來解決keep-alive這個問題吧, 這次就是這樣, 希望與你一起進步。