ReactJS Flux應用程序目錄結構

我的團隊目前正在研究使用Facebook的Flux架構在ReactJS中編寫的大型應用程序。目前它還處於初級階段，但它很快就會變大。它將擁有超過50個小組件視圖，大量行動，商店和行動創造者。ReactJS Flux應用程序目錄結構

目前，我們的目錄結構如下 -

App 
|___ module_1 
| |___ components 
| | |___ component1.react.js 
| | |___ component2.react.js 
| |___ module1ActionCreators.js 
| |___ module1Constants.js 
| |___ module1store.js 
| 
|___ module_2 
    |___ ... (same structure as above)

一個這種方法的問題是，因爲這個應用程序的增長module_x文件夾將在數量越來越大。

有沒有人有任何分享關於他們如何構建他們的應用程序？根據我們的經驗，Facebook的示例應用程序（待辦事項和聊天）具有適用於小型應用程序的架構，但一旦這些商店，組件和操作數量增加，就變得難以管理。

在此先感謝。

來源

2015-04-29 kalehv

如果某個組件足夠普遍且足夠可重用，那麼將其分解到自己的npm模塊中。如果您慷慨，請將其開放源代碼並列在http://react-components.com/ –

我認爲這是大型應用程序的發展方向。但是你的模塊可能太小了。我的應用程序目前按類型排序，如@ fisherwebdev的答案和每個流量示例所示，但我相信這並不能很好地擴展。商店文件夾中已有25家商店。我打算'按功能排序'而不是'按類型排序'，這些功能中的每一個實際上都是一個小的「應用程序」，它將插入「核心」應用程序。這些應該只依賴於'核心'模塊。但這只是一個想法。尚未設計。 – RoryKoehein

@RoryKoehein你設計了一些東西還沒有嘗試？我認爲這是正確的方法。這就是我們如何做到的，除了我們在功能中再次按類型排序，導致只有少量文件存在的額外文件夾大量加載。 – froginvasion

通常的目錄結構更是這樣的：

 
js 
├── AppBootstrap.js 
├── AppConstants.js 
├── AppDispatcher.js 
├── actions 
│ ├── AppActions.js 
│ ├── FriendActions.js 
│   └── PhotoActions.js 
├── components 
│ ├── AppRoot.react.js 
│ ├── friends 
│ │ ├── Friend.react.js 
│ │ ├── FriendList.react.js 
│ │ └── FriendSection.react.js // a querying-view, AKA controller-view 
│ └── photos 
│  ├── Photo.react.js 
│  ├── PhotoCategoryCard.react.js 
│  ├── PhotoCategoryCardTitle.react.js 
│  ├── PhotoGrid.react.js 
│  └── PhotoSection.react.js // another querying-view 
├── stores 
│ ├── FriendStore.js 
│ ├── PhotoStore.js 
│ └── __tests__ 
│  ├── FriendStore-test.js 
│  └── PhotoStore-test.js 
└── utils 
    ├── AppWebAPIUtils.js 
   ├── FooUtils.js 
    └── __tests__ 
     ├── AppWebAPIUtils-test.js 
     └── FooUtils-test.js

CSS的目錄通常看起來像部件目錄的反射鏡，每個部件的一個CSS文件。但是，現在有些人喜歡在組件上完成所有他們的樣式內聯。

不要總結所有這些 - 有而不是在商店和查詢視圖或「部分」之間始終是1：1，就像在此示例中那樣。

真的，你只需要做適合你的應用的東西。這不是教條。數據流的東西，控制的反轉和商店的解耦 - 這些比你組織文件更重要。

來源

2015-05-01 06:57:53 fisherwebdev

確實，其他的東西比文件夾結構更重要。另一方面，文件夾結構可以爲您（或未來的開發者）提供一個很好的想法。我幾乎認爲文件夾/子文件夾/文件模型是不夠的，並且提供更多靈活性的IDE可能是有用的（例如，文件夾圖形而不是文件夾樹）。 –

保證在這裏以及：http://andrewcallahan.com/towards-a-simpler-react-folder-structure/ –

因此，等待......每當你使用一個動作，你必須導入'「../../ someActions「'？如果您需要使用任何實用程序，則需要使用幾個文件夾。當然，它已經比我的文件夾結構更平坦了。 – froginvasion

我還在爲大型應用程序的初始結構做出決定。在將應用程序分成基於助焊劑角色的文件夾（即動作，存儲器，常量等）之後，我花了一段時間與你的結構非常相似。

首先，如果您使用的是類似Broswerify的東西，那麼在您的require調用上的相對路徑是可愛的。其次，當你在一個特定的組件上工作時，不必在各種文件夾中搜索文件是一個巨大的節省時間。

對於橫切問題，如調度程序，幫助函數，引導程序等，我有一個等效的應用程序模塊。對於我正在使用的每個文件而言，它總是覺得有一個明智的位置，而新開發人員並不努力查找相關文件（當模塊可能共享前綴時出現問題）。

由於切換，我還沒有回頭。

來源

2015-06-17 20:40:20

ReactJS Flux應用程序目錄結構

回答

相關問題