掘金 AMA：聽《React 狀態管理和同構實戰》做者--LucasHC 說 React 和前端那些事

第十七期 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 優化了這些點：

1. 啓動配置 Setup，簡化 store 建立等
2. 簡化 reducers 編寫 Simplified reducers
3. 對於異步的處理，Async actions, Async/Await 取代 Thunks 方案
4. 不須要在編寫 action type

所以從開發效率上來講，我我的以爲使用 rematch 或者 dva 都比原生手寫 Redux 來的實在。問題在於，使用這些上層封裝以後，也會帶來調試的「不便」，好比你不知道爲何 action 就被 dispatch 了，爲何異步就被「安排的明明白白」了。

如何作選擇？固然是在瞭解 rematch 這些方案的基礎上，知其然，知其因此然，那就放心使用這些吧，必定能發揮更大威力。咱們團隊也有本身的解決方案，使用起來清爽無比～

react服務端渲染前景怎麼樣？ ─ @yuyurenjie

react服務端渲染前景怎麼樣

固然是要看具體場景了。適合業務需求，何樂而不爲？因此須要分開看吧。

產品對 SEO，首屏加載要求高，SSR 就又發揮的空間。前景確定會有「一席之地」對，可是要看具體項目，大規模應用那倒也是不可能的吧

項目初期技術選型應該根據哪些因素來選擇？ -@gshisan

項目初期技術選型應該根據哪些因素來選擇（拋開團隊因素）

您好，感謝提問。

1. 學習成本和複雜度（若是團隊大部分都 hold 不住，那確定不行）
2. 相關技術選型的生態以及成熟度（若是沒人用，維護者不積極維護，很差）
3. 關鍵環節的兜底能力（若是相關技術選型執行一半有問題，能不能有人出來解決）
4. 備選方案能不能及時跟進

固然，最重要的是是否貼合業務。

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 下面交流技術喲，傳送門。

往期 AMA

• 2018 年掘金 AMA 年度總結：16 位技術大牛他們的技術事