在用前端框架如vue,react的時候,開發流程是怎樣的?

02-17

先寫完項目再拆分可復用組件,還是先把單個組件做好再拼成App?
相關問題: 寫前端頁面的時候，是先把html骨架寫好再寫css，還是一邊寫html,一邊寫css?

拿到需求以及原型以後，做如下事情

1.分析哪些模塊使用量大，可否構造復用組件

2.哪些模塊存在技術難點，有沒有成熟的方案還是需要自己寫解決方案（我這個人懶，基本上懶得找，不太麻煩的一般都自己造輪子）

3.哪些模塊會請求大量數據，生成大量DOM存在性能瓶頸

4.許可權細節的一些設計，許可權的細粒度規劃

5.全局的數據流向，構建整個項目的API目錄，考慮子模塊如何方便調用

確定以上問題以後，開始構建前端的架構設計，各個模塊的組織。我主要側重後台管理系統的，對於彈窗，表單處理的很多，這些呢大部分都可以從以前的項目中把代碼拿過來，也沒有什麼太大的技術問題，畢竟搬磚日久，熟能生巧。

在一個vue組件的實現細節上，有以前的組件能抄就抄，沒有的話先設計HTML，再設計CSS，最後完成JS部分。然後等來數據聯調。

有一點值得注意的是，不要過份追求組件的復用，曾經試過把幾個相似的大型表單組件合併為一個通用的組件，雖然最後成功了。但是要處理變化差異的邏輯，反而提升了複雜度。所以，業務代碼能拆開還是拆開好，免得以後改需求就起飛了。

不是應該先搭架子么。

選擇好框架+UI框架，以及layout，路由，狀態管理庫，封裝一個http後。。

然後再寫組件的么

當然先組件，難不成項目寫完再重構去拆么

第一步：需求和前期分析

1：考慮多頁還是單頁，是否需要SEO。

2：考慮擴展性，是使用官方推薦腳手架，還是自己寫webpack。

3：考慮團隊規範，是否需要引入TS／Flow來約束，引入airbnb ESlint約束，定製合適的校驗規則。

第二步：圍繞實際需求進行構建項目結構和三方包選型

1：按照需求中的Domain進行路由級別的拆分Page Component

2：選擇合適的UI類庫、請求庫、是否需要mock

3：創建合適的項目目錄結構/component/layout/utils/route/common之類。

4：是否需要引入狀態管理類庫，以及適合業務複雜度的狀態管理類庫的選型

第三步：觀摩根據原型圖，交互圖，任務分配

1：團隊成員共同找出原型圖中可復用組件，做好需要開發的可復用組件列表。

2：團隊成員，分配任務。

3：按照優先順序，開發page級別的頁面。分配團隊人員進行業務開發和基礎復用組件開發。

然後回答一下先後順序，

1：簡單的應用，先開發公用組件。

2：相對複雜的應用，先開發顯而易見且開發周期短的dump組件，然後開發業務，最後抽取公用業務組件。

根據項目實際情況吧，如果是瀑布式的開發，出一個設計做一套頁面那種，建議採用先寫項目再拆分組件，然後根據不同頁面需求調整組件，因為在這種模式下開發，你並不知道能復用多少東西（基礎組件除外），盲目拆分組件會導致開發效率變慢，以及代碼冗餘等狀況。

如果是項目重構，或者最開始就有比較好的項目原型設計，那大可以先寫組件再拼成APP，從項目整體入手再逐步分化，可以大幅提升開發效率。

瀉藥。

首先一句話，過早優化是萬惡之源。

首先看團隊，是專業團隊，還是小公司一人扛到底？

再次，搞清楚自己的需求，這點尤為重要，不管框架，類庫，殺雞用牛刀，肯定不行

這些都做好了，從ui圖抽取，能復用的小塊組件，既然題主問了vue.react，還是按組件文件的寫法來吧，抽取這些一小塊一小塊的東西，去考慮封裝的難易程度，這塊兒規劃好，那就大體有目標了，只需要關注實現了

既然組件化也提了，就當下流行的，構建工具得來一個吧，webpack？parcel?隨意，哪個熟用哪個，

實現的時候呢，就需要考慮數據層了，是多個數據源么，需要node做一個代理層么，有沒有性能方面的要求，有許可權方面的要求嗎，顆粒粗細程度呢？

大概需要做的就是這麼多，順序就湊合看吧。

以上。

拿到需求根據個人能力初步設計，這個階段不需要考慮的太細緻，把很明顯可復用的提出來就行了。經驗不足的情況下很難在這個階段把可服用組件都想到。

然後在具體實現的過程中再進一步完善。畢竟你在一個項目里同樣的代碼重複寫三次以上你自己就煩了，你就會思考怎麼把這部分作為一個可復用組件了。

慢慢鍛煉，你會發現以後每個新項目初步設計都會比上個看到可復用的地方多。

最後也不需要強行把一些組件做成可復用的，畢竟要兼容一種功能就肯定要增加組件內部代碼複雜度，而且以後萬一改需求，那你就笑了。所以看情況而定！

vue-cli init。
把以前的模板src弄過來，主要是目錄結構和封裝好的http。
安裝ui庫。
開始寫，寫的過程中拆一切。
碰到類似的就去拆的一切上擴充介面。

這個得看具體項目，業務場景。

最簡單的一個頁面就是直接引入cdn的react或vue，在script標籤裡面就可以開發了。

拿到需求先思考需求是否合理，整體實現是否有難度？如果涉及領域模型，一般會先簡單定義出模型，基於模型去考慮業務邏輯。如果未涉及業務模型，一般是直接寫組件。

我的習慣是組件儘可能拆分，能提取的配置和常量盡量提到文件頂部分明，這樣一目了然，後續修改很多時候也只需要改配置或聲明，維護成本低，也不容易出錯。