React-沒有Redux的可擴展架構（MVC DDD方法）-有解無憂

介紹

React 真的很靈活，我們在編程介面時似乎并沒有強迫我們遵循特定的架構，不像其他庫，它有點像撰寫一個普通的視圖。對于小型 Web 應用程式，這很酷，但是……一旦您的應用程式開始增長，您撰寫代碼的速度就會逐漸降低，這與您從原則一開始就定義了架構相反。

我的建筑

就我而言，我沒有使用 Redux 進行狀態管理……相反，我使用的是 React Context React Hooks。

這是我當前的專案結構（使用 firebase 構建的無服務器應用程式）：

/app
   /components
      /Activity
      /Authentication
      /Profile
      /Buttons
      /Text
      /Inputs
      /Giphy
      /Messaging
      /HOCs
      ...

   /screens
      /Activity
      /Authentication
      /Profile
      /Messaging
      ...
   
   /contexts
      /Users
      /Content
      /Auth
      ...

   /hooks
      /auth
      /profile
      /users
      /content
      /badges
      /i18n
      ...

   /navigation
      /Stacks
      /Tabs
      ...

   /services
      /third-party
      /firebase 
         /api
      ...

   /lib
   /theme
   /styles
   /utils


/functions (backend)

正如您所注意到的，我正在使用某種領域驅動的設計來構建我的專案檔案。

Also, I am separating concerns from screens and components using hooks, and managing complex state (or which need to be synchronized between routes) inside contexts that contains the respective reducers.

This seems to me like some kind of MVC. Where the View is composed by all my React Functional Components, the controller is composed by all my Business and UI hooks, and the data of my Model is contained inside Contexts (or, at least the dynamic data, because of efficient reasons).

As you can see, I have a folder "services" which is just the interface that my business hooks use in order to connect to my server (cloud functions).

Questions

Does this architecture have a name (flux/redux??)? I mean, with the passage of time as a React programmer, mistake after mistake, I have ended up organizing my projects like this, in a "natural" way.
Is it an anti-pattern to split all my components logic with hooks? I mean, all the functional components of my project just contain the event handlers or the JSX to render the UI. I have moved every single block of code to hooks, some of them contain the logic of my business, others simply complex logic related to the graphical interface (animations, ...)
Which advices do you give to me in order to refine my current architecture?
useSelector with React Context? I have implemented some custom hooks that just read and compute derived data from contexts... as I can't use "useSelector", I don't know if this is something typical, because they just consume the necessary contexts (useContext) and then execute some calculations.
Is it Redux really necessary? For a medium-large project, I have handled it well using React Context and with the help of the hooks my code has been quite clean. Do you think that over time, as the project continues to grow, it will be necessary to move to Redux?
Are react hooks the controllers of an application?

uj5u.com熱心網友回復：

好吧，不完全確定這是提出此類問題的正確位置，但讓我們嘗試從我的角度回答這些問題。

答案

我不認為這個特定的架構有一個名字（例如，這個有一個名字https://www.freecodecamp.org/news/scaling-your-redux-app-with-ducks-6115955638be/）。在任何情況下，名稱都不會是“Flux”或“Redux”，因為這些名稱更多地與資料的處理方式有關，而不是專案中檔案夾的結構方式。我不認為有一些關于檔案夾層次結構的嚴格規則可以完全符合 Flux 或 Redux 模式。當然有最佳實踐和約定，但它們不是強制性的。
為了回答這一點，讓我分享這個鏈接https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0關于 Dan Abramov 發表的一篇文章。我分享這篇文章是因為上次更新（這篇文章的日期是 2015 年，但 2019 年有一個重要的更新）。正如您所看到的，您似乎做得很好，因為您將核心邏輯置于掛鉤中。請注意這一點：您說的是“功能組件”，但我認為您指的是“表示組件”，這是一個重要的區別，因為“功能組件”意味著您的組件基于函式（而不是類），“表示組件”則表示該組件不包含業務邏輯。“表示組件”既可以是基于類的，也可以是功能性的，功能性組件可以包含業務邏輯（基于類的組件正在被功能性的組件所取代，
一些建議：大小寫和大小寫保持一致（你混合了大寫和小寫，破折號和駝峰式，通常我喜歡用破折號命名每個檔案或檔案夾，但這取決于你）；確定HOCs檔案夾是否應該在這里；也許你可以把所有的 utils（lib, theme,styles和utils它本身）放在一個名為的目錄中utils，每個 util 被命名為屬性；
關于背景關系，這是一個有爭議的話題，只是想分享從檔案https://reactjs.org/docs/context.html#before-you-use-context 中獲取的一些注意事項，并分享我對此的看法。根據檔案副標題，背景關系背后的想法是“背景關系提供了一種通過組件樹傳遞資料的方法，而無需在每個級別手動向下傳遞道具”。因此，基本上，它是為了避免“財產鉆探”而創建的，例如此處公開的https://medium.com/swlh/avoid-prop-drilling-with-react-context-a00392ee3d8。這只是個人觀點，但也許引入 Redux 進行全域狀態管理比使用 Context API 更好。
不要害怕使用 Redux。如果在使用 Redux 時有大量重復的代碼行，請害怕。在這種情況下，您應該考慮如何抽象您的動作和減速器（例如使用動作創建者）。如果您能夠概括諸如“從后端獲取專案串列”之類的內容，您將意識到您的代碼不僅比重復的代碼行更少，而且更具可讀性和連貫性。例如，對于串列，您可能有一個動作，例如const getListOfNews = list("NEWS_LIST", "/api/news/");where listis an action creator like const list = (resource, url) => (params = {}) => dispatch => { // your implementation... };，類似于 reducers。
不，它們只是“讓您無需撰寫類即可使用狀態和其他 React 功能”，如此處https://reactjs.org/docs/hooks-intro.html來自 docs所述。避免嘗試將像 MVC 這樣的模式適應用不同想法創建的東西是很重要的，這是一個一般性建議。就像如果您來自 Angular，并且您嘗試在 React 中以相同的方式作業。基本上你應該使用 React 或其他庫/框架，而不是試圖將它們從它們的本質轉換成你已經知道的東西。

轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/359559.html

標籤：javascript reactjs react-native redux architecture

上一篇：ReactNativeUseEffectAPI呼叫

下一篇：ReactNative-Pressablelongpress上的連續文本輸入洗掉