第十七期 AMA 掘金團隊請來了《React 狀態管理和同構實戰》作者--LucasHC 做了為期三天的 Ask Me Anything (AMA) 活動（活動已結束）。第十九期 AMA 正在進行，歡迎去和 Android 技術專家--任玉剛聊聊你的技術疑問和看法，提問傳送門
我們在此精選了一些來自使用者的提問及 LucasHC 的回答。
關於 LucasHC
《React 狀態管理和同構實戰》作者，知乎「前端開發」話題優秀回答者。曾職於百度知識搜尋部，負責部門內技術更新迭代，工程專案落地實施；也曾服務於法國能源和蘇伊士集團、矽谷 BePATIENT 集團。
社群小夥伴精選提問--技術直接相關
業內有哪些工具或 npm 庫或開發模式是可以確切能夠幫助解決痛點或者改善現狀的呢？？ ─ @黃大發丶
Lucas 前輩你好，我是前端小白黃大發同學。我們組內面臨著最古老的 react 管理平臺重構任務，這次我們想生成關於我們管理平臺的閱讀文件(包括常用的 樣式命名 工具方法 全域性元件 複雜api互動流程 等)。
所以我想提出的問題是：面向 react 程式碼的可維護性和可持續發展(不要單個功能每個團隊成員都實現一遍)(新成員加入的時候知道有哪些功能能從現在程式碼中複用 也知道有哪些功能還沒有他可以新增實現進去)，業內有哪些工具或 npm 庫或開發模式是可以確切能夠幫助解決痛點或者改善現狀的呢？
謝謝前輩耐心閱讀完問題。??
感謝提問，第一個問題我認為提的非常好，非常有意義。
的確，面臨專案負責度的提升，各種元件也“爆炸式”增長。如何讓這些元件們方便易用，同時能快速上手，不成為負擔，又避免重複造輪子現象，良好的元件管理在團隊中非常重要。
關於「React 元件管理文件」我可以簡單梳理一下，總的來說，社群上在這方面的探索很多，相關方案也各有特色：
1）最知名的一定是：storybook，請參考 https://storybook.js.org/網頁連結 他會生成一個靜態頁面，專門用來展示元件的實際效果以及用法。缺點：業務侵入性較強，且 story 編寫成本較高。
2）接下來是我個人很喜歡的 react-docgen，比較極客風格，它能夠分析並提取 React 元件資訊，原理是使用了 recast 和 @babel/parser AST 分析，最終產出一個 json 文件。https://github.com/reactjs/react-docgen網頁連結，缺點：它較為輕量，缺乏有效的視覺化能力。
3）那麼在 react-docgen 之上，我們可以考慮 React Styleguidist，這款 React 元件文件生成器，支援豐富 demo，我想可能會更符合您的需求。
4）一些小而美的解決方案，比如：react-doc，react-doc-generator，cherrypdoc，甚至 ant-design 的 Bi Sheng。
5）“自己動手，豐衣足食”，其實開發一個類似的工具並不會太複雜，也還是比較有趣的。比如，redemo https://imweb.github.io/redemo/網頁連結，我也自己實現了類似的平臺。有過有時間和精力，有興趣您可以根據自己的需求，實現一個完全 match 自己團隊的React 元件管理文件。
總結： 推薦程度按照次序排列，最終如何選用還需要您自己根據實際情況做判斷。 不知道有沒有回答您的問題，還有疑問可以追問。
Happy coding!
在你看來，什麼場景適合react來進行開發呢？ ─ @rocky191
之前用的是vue，現在想學學react，感覺有些地方比vue麻煩，資料的繫結修改，每次都得手動呼叫setstate，增加了一定的複雜性。在你看來，什麼場景適合react來進行開發呢？
您好，感謝提問。
“每次都得手動呼叫 setstate”這種非雙向繫結的操作，可能暫時讓您感覺不舒服。但是這也增加了開發者對於程式的把控性、可調式性，主動權在開發者手裡。
setstate 正式 React： UI = f(data) 的核心關鍵，我相信目前您的困擾更多是習慣的問題，在熟悉 React 之後，會感到他的清爽和便利。
另：setstate 只是處理元件內部自己的資料狀態，在大型應用中，這種場景並不會非常非常多，更多的是基於 Redux 或者 Mobx 等對於資料狀態的管理。開發者主要關心的是對於資料的設計和貫通，完成正確不可變形流轉即可。
為什麼似乎目前react選型公司更多些呢？ -@小小石馬農
請問在為專案選擇前端技術方案的時候，什麼情況下適合用react，有哪些考慮因素？react相對來說比vue開發成本更高，但是為什麼似乎目前react選型公司更多些呢？
您好，感謝提問。
我認為，即便“react 相對來說比 vue 開發成本更高”，那麼高出的成本也是有限的。且高出來的這些成本會在：維護成本、複用設計、減少潛在 bugs、生態豐富程度等環節中獲得收益。
請問什麼場景使用mobx，什麼場景使用redux？ -@lunarsprite
請問什麼場景使用mobx，什麼場景使用redux？還有您對Umi和Dva如何看待？謝謝。
您好，感謝提問。
mobx 和 redux 解決問題類似，都是針對 React 應用當中的資料狀態管理的解決方案。但是它們實現以及使用理念有較大差異，對於技術選型，還是看團隊風格和喜好吧。這兩者都比較成熟可靠，個人認為 mobx 更靈活，甚至更偏向物件導向和 Vue 風格，也許在程式碼量上相對 Redux 有所優勢。但是 Redux 這種純函式的…
我們怎麼在redux，rematch或者dva這些庫之間做選擇？ -@王宇靖
在做狀態管理時，用redux會造成程式碼增長速度很快，我們怎麼在redux，rematch或者dva這些庫之間做選擇？
您好，感謝提問。
Redux 確實有一些遭人詬病的一些“問題”（可以參考我在知乎的回答：https://www.zhihu.com/question/263928256/answer/274963347網頁連結）
因此就像你所，很多面向簡化 Redux 封裝的解決方案很多。 比如 Rematch，比如 DVA。就像我所說，這些解決方案無外乎針對 Redux 優化了這些點：
- 啟動配置 Setup，簡化 store 建立等
- 簡化 reducers 編寫 Simplified reducers
- 對於非同步的處理，Async actions, Async/Await 取代 Thunks 方案
- 不需要在編寫 action type
因此從開發效率上來說，我個人覺得使用 rematch 或者 dva 都比原生手寫 Redux 來的實在。問題在於，使用這些上層封裝之後，也會帶來除錯的“不便”，比如你不知道為什麼 action 就被 dispatch 了，為什麼非同步就被“安排的明明白白”了。
如何做選擇？當然是在瞭解 rematch 這些方案的基礎上，知其然，知其所以然，那就放心使用這些吧，一定能發揮更大威力。我們團隊也有自己的解決方案，使用起來清爽無比～
react服務端渲染前景怎麼樣？ ─ @yuyurenjie
react服務端渲染前景怎麼樣
當然是要看具體場景了。適合業務需求，何樂而不為？所以需要分開看吧。
產品對 SEO，首屏載入要求高，SSR 就又發揮的空間。前景肯定會有“一席之地”對，但是要看具體專案，大規模應用那倒也是不可能的吧
專案初期技術選型應該根據哪些因素來選擇？ -@gshisan
專案初期技術選型應該根據哪些因素來選擇（拋開團隊因素）
您好，感謝提問。
- 學習成本和複雜度（如果團隊大部分都 hold 不住，那肯定不行）
- 相關技術選型的生態以及成熟度（如果沒人用，維護者不積極維護，不好）
- 關鍵環節的兜底能力（如果相關技術選型執行一半有問題，能不能有人出來解決）
- 備選方案能不能及時跟進
當然，最重要的是是否貼合業務。
React 升級經驗或者建議? -@清秋
在做的一個 16 年開始的存量專案需要進行 React 升級，發現牽一髮而動全身，React 從 v15 升級到 v16，發現使用的一些第三方庫是依賴 React 15 版本的，如 antd，也要隨之升級，還有非常大量的存量程式碼需要隨之調整。想問LucasHC 有沒有類似的升級經驗或者建議，可以少走一些彎路，感謝。
您好，感謝提問。
升級的話，自己業務還好說，掌控權都在自己手上。可能就是工作量稍微大一點，因此需要記得及時更新，而不是多個大版本之後才去行動，這樣帶來的成本極大。
確實如你所說，第三方庫這方面那就很尷尬了，除非自己 fork (不是特別現實)或者提 PR，一般這些庫都 PR welcome 的吧。這也就涉及到對庫的選擇問題了。。。
從mvc到flux到redux再到很多其他的方案，狀態管理演化的過程有什麼規律？未來它的趨勢是什麼？ -@依然君
大神您好，我對於前端狀態管理很感興趣。我想問，從mvc到flux到redux再到很多其他的方案，狀態管理演化的過程有什麼規律？未來它的趨勢是什麼？
您好，感謝提問。
狀態管理演化的規律永遠都是向便捷性和維護性這兩個終極目標發展。具體設計實踐又會受到依託的“宿主” React，我看了看 Redux 每個版本的迭代，其實非常有意思，感興趣可以看一下。
未來趨勢，應該還是 Redux 為主的函式式和 Mobx 為主的偏向物件導向的響應式分立吧，只不過 React 最近幾個大版本的變更，會讓這些狀態管理方案收到一定衝擊。
非技術相關--閒聊篇
為啥程式設計師擺拍都這麼騷? -@雲夢
為啥程式設計師擺拍都這麼騷?
感謝提問。。。
這個嘛，因為“我不高不帥，沒老婆沒孩子，但是，我！騷！啊！” ?
如何看待前端新人從事打雜工作以及頻繁跳槽的現象？ -@jsChan
對於初入這個行業的年輕人來說，你是如何看待前端新人從事打雜工作以及頻繁跳槽的現象，你自己在剛入行的時候具體是參與什麼工作，工作內容是什麼？
您好，感謝提問。
這些問題很有意義，我依次回答：
1）作為新人的話，如果從事打雜業務，我們也可以從中吸取成長的養分。這些工作非常適合打牢基礎，為以後進階提供紮實的基礎保障。同時也可以思考：這些打雜的活動是不是能夠用技術的手段化繁為簡？比如經常要做的繁瑣 H5，運營頁面等，是否可以提取出共性，將這些“打雜”變小，變無。
2）頻繁跳槽的話肯定不是一個好的現象。這個需要跳槽者自己看清楚各個階段究竟需要的是什麼。
3）以我個人經歷，cover 一下上邊兩個話題。我剛參加工作，也做“打雜”需求，但是通過這些需求快速查漏補缺，完善基礎。同時思考如何能夠將這些繁雜事情抽象，減少後續開發成本。跳槽的話，我在路徑是：應屆畢業後大公司工作 3 年，完成職業素養的養成和開發規範化塑形，同時開拓視野，之後在獨角獸公司工作 1 年左右，嘗試各種挑戰，將自己積累的技能加以應用。
怎麼寫好複雜業務程式碼？-@尹光耀
hi，在工作當中，業務是很重要的一部分，有時候甚至高於技術，對於剛畢業一年多的人來說，怎麼寫好複雜業務程式碼？還有就是技術該如何推動業務發展呢？
感覺我問得太籠統了。在互動特別多的場景下，由於一開始沒有想到那麼多情況，導致最後修修補補，原來的程式碼就不忍直視了。即使我對service、controller和format做了分層，但controller還是會很大，最後總是可讀性特別差。自己平時會研究react、redux、mobx之類的原始碼，但是這些在專案中還是用不到，頂多寫寫部落格告訴他們怎麼用。研究這些深入的東西，怎麼才能和業務結合到一起呢？
您好，感謝提問。
這個問題我個人認為提的非常好。針對：
1）如何寫好複雜業務程式碼：這個不是一簇而成的，肯定是需要經驗積累，跌跌撞撞才能有所心得。你現在也能發現自己的一些問題，比如覺得自己對於複雜需求，程式碼寫的“可讀性差、初期設計不完善”，這正是在進步的體現。我認為寫出組織良好且設計相對完美的程式碼，沒有捷徑，你現在已經在正確的路上進步了。同時建議多看看大型專案原始碼，對症下藥。比如針對這個問題，看 React 之類的原始碼也許不如看一個應用層級更高，或者知名實戰專案的原始碼更適合。
2）您說的“自己平時會研究 react、redux、mobx 之類的原始碼，但是這些在專案中還是用不到”，我是完全深有體會。因為我接觸這類技術棧時，公司也完全用不到。這時候我的做法是，先深入理論，在知識層面完全掌握這些內容（這個靠技術興趣和自驅力了），然後有合適的機會要敢於創造挑戰，比如在團隊推廣並應用落地。我當時正好碰上了一個很適合 React 開發的專案（即時通訊平臺），並說服團隊採用 react、redux 技術，平時在這方面的積累得到了真實應用。
3）在此之前，怎麼才能和業務結合到一起呢？我的做法是思考業務中適合使用 React 實現的 feature，私底下做了一個 React 版本的實現。這會為後續 React 推廣打下基礎，至少你自己得先能 hold 住各種業務需求吧。
本期 AMA LucasHC 也回答了很多其他的技術、非技術問題，歡迎去他的 AMA 下面交流技術喲，傳送門。