還記得以前為了找文件上沒有的救命 function,得花大把時間慢慢翻閱套件的原始碼嗎?
之前就聽說了 Deepwiki,一個能解決這個痛點的工具,今天終於有時間可以來試試看。順便藉這個機會,也想深入了解一下專案中使用的狀態管理器套件 Riverpod,看看有沒有什麼好用但自己從來沒發現的功能,好好為自己升級一下。
Deepwiki 的用法非常直覺。你只需將 GitHub 專案的網址(例如:https://github.com/rrousselGit/riverpod
),把 github.com
替換成 deepwiki.com
,就會變成:https://deepwiki.com/rrousselGit/riverpod
。
如果這個專案是 Deepwiki 第一次讀取,它可能需要幾分鐘的時間來解析,你可以留下 Email,等解析完成後它會主動通知你。
由於人在外面我用手機版測試了 Deepwiki,整體體驗還不錯。介面下方有一個輸入框,讓你可以隨時提出任何問題。不過有個小問題,當它正在回應時,建議先不要滑動畫面,以免因資訊未完全生成而導致滾輪位置閃爍。
我的第一個問題是關於 Riverpod 的架構。Deepwiki 的回答與我對 Riverpod 的理解相符,並且還會附上相關的參考連結。
接著,我嘗試提出更深入的問題:「我想更深入了解 autoDispose。」
Deepwiki 不僅解釋了核心概念,還順便介紹了相關的生命週期,例如:keepAlive
,以及我從未使用過的生命週期回調函式:ref.onCancel
、ref.onResume
、ref.onDispose
。於是我請它提供使用情境並撰寫範例。
有趣的是,第一次請它寫範例時,它好像有點「過度思考」,等了很久都沒有回應,甚至連語系都跑掉了。後來我調整了提問方式,把問題改成「幫我介紹 ref.onCancel
、ref.onResume
、ref.onDispose
的使用情境」,它就神奇地成功生成範例了!
雖然沒有實際測試,無法確定程式碼是否完全正確,但這個經驗讓我學到一課:如果 Deepwiki 的回應不如預期,可以試著調整提問方式或切換模式(例如關閉 DeepResearch),有時候反而會得到更好的結果。
我接著隨機問了幾個問題:
Deepwiki 的回答都達到了我的預期,並且與我的認知相符。更棒的是,我還因此學到了兩種新的 listen 參數:
fireImmediately
:立即觸發監聽器,這個功能非常實用。
ref.listen(
provider,
(previous, next) => print('Value changed'),
fireImmediately: true,
);
weak
:不會導致 provider 初始化的弱監聽。
ref.listen(
provider,
(previous, next) => print('Value changed'),
weak: true,
);
最後,我向 Deepwiki 提出了一個開放性問題:「如果我想優化效能,有什麼建議的實作方式嗎?」
它的回答非常詳盡,從最常見的 select
到我較少使用甚至沒用過的方法,都分門別類地條列出來。
Deepwiki 提供的幾項主要性能優化策略:
ref.read
來獲取會更新的 UI 值。Consumer
放在需要監聽變動的最小範圍內,避免整個 Widget 樹重建。Consumer
中使用 child
參數來緩存不變的子 Widget,避免重複建立昂貴的元件。autoDispose
和 family
,有效防止記憶體洩漏。Provider
自行初始化,保持邏輯分離。selectAsync
來同時等待值和過濾重建。這次初次使用 Deepwiki,我感到收穫滿滿。儘管由於手邊沒有電腦我還無法確定它提供的所有程式碼是否完全正確,但它確實幫助我吸收了許多新知。
不論你是剛開始接觸一個新套件,或是想學習更深入的技巧,Deepwiki 都是一個不錯的助手,能讓我們對專案的了解更加全面。