React 프로젝트를 구성하는 방법

나는 React 프로젝트 (또는 어떤 언어를 사용하는 어떤 프레임워크를 사용하는 프로젝트) 의'정확'방식을 이야기하는 것이 마치 헤어스타일을 이야기하는'정확'방식과 비슷하다는 것을 완전히 이해한다.(객관적으로 정확한 헤어스타일이 모호크 스타일이라는 것에 동의한다고 생각하지만)
비록 프로젝트의 구조는'기본적'일 수 있지만 이 게임에서 4분의 1세기를 놀은 후에 나는 여전히 나의'기본적'프로젝트 구조를 끊임없이 조정하고 발전시키는 것을 발견했다.따라서 제 Spotify Toolz 프로젝트(https://www.spotifytoolz.com의 더 많은 전술 세부 사항을 깊이 연구하기 전에 저는 현재 React 프로젝트를 어떻게 조직하는지에 대한 빠른 글을 쓰고 싶습니다.
나도 관중의 참여를 환영한다.지금이라도 이 모든 시간에 코드를 던진 후 6개월 정도면 나는 놀라운 인식을 갖게 될 것 같다. "이 데이터들은 정말 거기에 저장되어야 한다!"그래서 나는 너희들이 프로젝트를 조직하는 데 있어서 가장 좋은 실천을 보고 싶다.
'프로젝트 조직'과 같은 주관적인 문제들처럼 나는 현재의 방법이 경험적으로 가장 좋은 방법이라고 100% 보장할 수 있다.나는 또 어떤 다른 방법도 모두 틀렸다고 보증할 수 있다.6개월 후에 나는 완전히 다른 방법을 채택하여 프로젝트를 조직할 것이다.그때 나는 본문에서 조직에 관심을 가진 모든 사람들을 비웃을 것이다. 나는 그들에게 내가 이미 더 좋은 조직 방안으로 바뀌었다고 말할 가치가 없다.
만약 당신이 이 조직 계획을 사용하고 최종적으로 그것에 대해 불만족을 느낀다면, 나는 당신이 본문을 읽기 위해 지불한 150퍼센트의 비용을 반환할 것을 유쾌하게 제기할 것이다.

기본 조직

(위의 그림이 무엇을 의미하는지 모르겠다면 용서해 드리겠습니다. 유성기나 마차 채찍과 비슷한 물건이라고 하면 충분합니다.)
대부분의 (최신) React 프로젝트의 구조는 다음과 같습니다.

/src
  app.js
  /shared
    /classes
    /components
    /css
    /functions
    /hooks
    /objects
      /models
  /routes

응용 프로그램에 UI가 있다면, 보통 React Router를 사용할 것이라고 가정합니다.만약 내가 React Router를 사용한다면, /routes 디렉터리는 사용자가 응용 프로그램에서 내비게이션을 할 때 볼 수 있는 디렉터리의 일대일 표시가 될 것이다.
따라서 응용 프로그램에 users 모듈(/user이 있고 (/user-create, 편집(/user-edit, 보기(/user-view 사용자를 위한 별도의 "페이지"가 있으면 다음 항목과 같습니다.

/src
  app.js
  /shared
    /classes
    /components
    /css
    /functions
    /hooks
    /objects
      /models
  /routes
    /user
      /create
      /edit
      /view

또한 라우팅에 매핑된 어셈블리를 만들 때 해당 폴더 아래에 있는 JS 파일로 표시됩니다.따라서 각 노선의 기본 구성 요소를 작성하면 트리는 다음과 같습니다.

/src
  app.js
  /shared
    /classes
    /components
    /css
    /functions
    /hooks
    /objects
      /models
  /routes
    /user
      /create
        /components
          create.user.js
      /edit
        /components
          edit.user.js
      /view
        /components
          view.user.js

/routes/{routeName} 폴더 아래에는 직접 파일이 없습니다.루트를 정의하는 모든 내용은 논리적으로 classes, components, css, functions, hooks, objects 또는 /src/routes/{routeName}/components/{route.name.js} 폴더에 속해야 하기 때문이다.
실천 차원에서 이것은 나의 루트의 대다수 논리가 /src/routes/{routeName}/components/{route.name.js} 아래에 있다는 것을 의미한다.왜냐하면 나의 대다수 루트에 대해 모든 루트의 특정한 논리는 view.user.js 에 봉인되어 있기 때문이다.
이제 <ViewUser> getLastUserLoginTimestamp() 구성 요소가 될 것이라고 가정해 봅시다. getLastUserLoginTimestamp() 라는 함수가 필요합니다.내가 이 기능을 만들 때, 나는 조직 선택을 해야 한다.선택은 다음 질문으로 결정됩니다.

Will this function be used in this component, and only ever in this component??

만약 이 답이'예'(즉, 이 함수가 완전히 유일하고 이 구성 요소만을 겨냥한 것이라면) 나는 다음과 같은 구조를 만들 것이다.

/src
  app.js
  /shared
    /classes
    /components
    /css
    /functions
    /hooks
    /objects
      /models
  /routes
    /user
      /create
        /components
          create.user.js
      /edit
        /components
          edit.user.js
      /view
        /components
          view.user.js
        /functions
          get.last.user.login.timestamp.js

이 장면에서 나는 ViewUser 구성 요소에서만 /functions 함수를 사용하기로 결정했다.그래서 나는 /src/routes/user/view 디렉터리 아래에 단독 getLastLoginTimestamp() 디렉터리를 만들었다.이것은 ViewUser 구성 요소 내부에서만 사용된다는 것을 의미한다.따라서 이 함수를 수용하는 /functions 디렉터리는 /src/routes/user/view 아래에만 있어야 한다.
하지만 솔직히 위의 예는 드물다.보통, 내가 조수 함수를 만들 때, 나는 그것들이 전체 응용 프로그램의 다른 곳에서 사용될 것이라는 것을 이미 알고 있다.사실상, 설령 내가 그것들이 전체 응용 프로그램에서 어떻게 사용될지 확실하지 않더라도, 나는 통상적으로 내가 만들고 있는 기능이 최종적으로 다른 곳에서 사용될 것이라고 생각한다.
따라서 나는 함수를 특정 /src/routes/{routeName} 디렉터리에 놓는 일이 드물다.나는 자주 이 함수들을 /shared 디렉터리 아래에 놓는다.보아하니 이렇다.

/src
  app.js
  /shared
    /classes
    /components
    /css
    /functions
      get.last.user.login.timestamp.js
    /hooks
    /objects
      /models
  /routes
    /user
      /create
        /components
          create.user.js
      /edit
        /components
          edit.user.js
      /view
        /components
          view.user.js

나누는 게 관심이에요.

아직 잘 모르면, 내 프로그램의 "/src/shared"디렉터리는 나의 모든 응용 프로그램 논리의 대부분을 차지한다.이런 상황이 발생한 데는 두 가지 이유가 있다.

많은 클래스/구성 요소/스타일/함수/연결/객체가 처음부터 공통으로 설계되었습니다.설령 내가 어떤 특정 파일이 장래에 어떻게 중용될지 모른다 하더라도, 나는 통상적으로 이런 방식으로 파일을 작성하는데, 나는 그것들이 중용될 것이라고 생각한다.따라서 대부분의 파일은 /src/shared 아래에 저장됩니다.

주어진 클래스/구성 요소/스타일/함수/갈고리/대상이 한 경로에서만 사용할 것 같아도 파일을 /src/shared 아래에 저장하는 경향이 있습니다.

이것은 왕왕 나의 /src/shared 목록이 끊임없이 증가하는 잠재적 중용 자산 창고라는 것을 의미한다.이것은 내 /src/routes 디렉터리가 희소하지만, 사용자가 응용 프로그램을 통해 잠재적인 경로를 일대일로 비추는 것을 의미한다.

중요 사항

이 점에서, 나는 통상적으로 모든 React 구성 요소를 함수 기반 구성 요소로 작성한다.이것은 내가 사용하지 않는다는 것을 의미한다export class SomeComponent extends React.Component {...}.반대로 나는 쓴다export const SomeComponent = () => {...}.
따라서 위의 디렉터리 구조를 볼 때, 이 디렉터리는 클래스 기반 구성 요소를 포함하고 있음을 발견할 수 있습니다.하지만 사실은 그렇지 않다.
내가 선택한 프로젝트 구조에서 /src/shared/classes 실용 도구 조수 클래스만 포함한다.예를 들어, 나는 /src/shared/classes 의 조수 클래스 (여기서 읽을 수 있습니다:) 와 검증 라이브러리 (여기서 읽을 수 있습니다:) 를 자주 사용합니다.이것은 내가 최근의 React 개발에서 유일하게 진정으로 사용한 클래스다.localStorage 아래에 /src/shared 디렉터리가 있다는 것을 알게 될 것이다.이것은 노선을 정의하는 주요 구성 요소에 적용되지 않습니다.이것은 내가 전체 응용 프로그램에서 반복적으로 사용하는 모든 조수 구성 요소 (예를 들어 고급 구성 요소) 에 적용됩니다.
내 특정 방법에서 /components 폴더에는 실제 CSS 클래스가 포함되어 있습니다.만약 내가 JSX에서 내연 CSS를 사용한다면, 이것은 /src/shared/css 에서 정의한 것이다. (내연 CSS를 사용하기 때문에, 스타일은 자바스크립트 대상이기 때문이다.)
나는 /src/shared/objects 아래에 없는 갈고리를 거의 만들지 않는다.내가 보기에, 만약 갈고리가 영원히 여러 구성 요소 사이에서 공유되지 않는다면, 왜 하나의 기능 구성 요소를 사용하는 주체에서 그것을 정의하지 않습니까?
마지막으로 내가 사용한 /src/shared/hooks 은 일부 사람들을 곤혹스럽게 할 수도 있다.나는 나의 개발에서 많은 순수한 ol-JS 대상의 용례를 발견했다. 너는 여기서 예를 하나 찾을 수 있다. 여기:/src/objects의 사용에 대해 저는 제 검증 라이브러리로 설명했습니다. 간단하게 말하면 제 /src/objects/models는 함수에 전달된 대상의 형상을 검증하는 데 도움을 주었습니다.

너 거 보여줘.

이것이 바로 내가 현재 React 프로젝트를 조직하는 방식이다.(나는 우리가 모두 이것이 정확한 방식이라는 것에 동의할 것이라고 믿는다.)당신은 어떻게 당신의 프로젝트를 조직합니까?내가 뭘 소홀히 했나???알려줘...