프런트엔드 애플리케이션 확장 - 코딩 지침

10184 단어 frontendarchitecturereactscaling
제품과 코드베이스가 커짐에 따라 프런트엔드 애플리케이션을 구성하는 것이 까다로울 수 있습니다. 이 게시물에서는 거의 모든 종류의 프런트엔드 프로젝트 크기에 대해 작동하는 솔루션에 대해 내가 찾은 것을 공유할 것입니다. 이 지침은 duck pattern 이라는 패턴에서 크게 영감을 받았습니다.

Ducks의 전체 아이디어는 필요할 때마다 모듈화, 수정, 확장 가능 및 분해가 용이하고 상태 라이브러리 등과 같은 기술을 이동하는 방식으로 겉보기에 관련이 있는 파일을 함께 그룹화하는 것입니다.

오리는 무리를 지어 있을 때 최소한의 소란을 가장 많이 느끼는 외향적이고 사교적인 동물입니다.
오리 패턴의 핵심은 하나의 단위로 함께 작동하는 작은 파일을 함께 배치하여 작업을 쉽게 만드는 것입니다. 아래 지침을 참조하십시오.
  • Files and Folder Convention

  • Components
  • Presentational Components
  • Connected Components
  • Styling Components

  • Interacting with Backend
  • State sharing

    • 파일 및 폴더 규칙

    Using the feature pattern to colocate feature related files rather than by functions, lets take a look at a login example

    기능 우선 ✅



    Login/
  Login.tsx
  index.ts
  store/
    reducers.ts
    actions.ts

    "기능 우선"은 앱에 포함된 기본 기능(이 경우 로그인)을 따라 최상위 폴더의 이름을 지정하는 것을 의미합니다.

    각각의 새로운 기능은 자체 폴더와 함께 제공되기 때문에 이 기술은 훨씬 더 잘 확장됩니다.

    기능과 연결되지 않은 파일을 가질 수 있으며 이를 common/shared/core e.t.c라고 부를 수 있습니다. 제품의 여러 기능에서 코드를 재사용하기를 원하기 때문입니다.

    기능 우선 ❌



    Components/
  Login.tsx
  Signup.tsx
Containers/
  Login.tsx
store/
  reducers.ts
  actions.ts

    "기능 우선"은 포함된 파일의 목적에 따라 최상위 폴더의 이름을 지정하는 것을 말합니다.
    지금까지 컨테이너, 구성 요소, 작업, 리듀서 등이 있습니다.

    이것은 전혀 확장되지 않을 것입니다.
    프로그램이 발전하고 추가 기능이 추가되면 파일이 동일한 디렉토리에 추가됩니다.

    이 문제는 폴더를 함께 묶는 것과도 관련이 있습니다.
    프로그램의 단일 흐름은 거의 확실하게 모든 디렉토리의 파일을 편집해야 합니다.

    "기능 우선"접근 방식을 사용하여 다음과 같은 일반적인 프로젝트 구조를 생성할 수 있습니다.

    src/
  pages/ ---> Contains top level files rendering as a page
    login {feature-folder}/ ---> Would contains components, api|hooks|actions files & folders related to login pages, if these components are going to be reused elsewhere aside login, move it into the core/components directory.
  core/ ---> Globally shared, reusable, components and files JSX related.
    components/ ---> Globally Shared React components, mostly dumb/presentational components
      {ComponentName}/
        ComponentName.tsx ---> Using named exports e.g `export const ComponentName = () => {}` Always keep this file as simple as possible
        Styles.tsx ---> A case for using styledComponents, all created elements will be stored here, exported using named exports
        index.ts ---> exports { ComponentName } from './Componentname'
        utils.ts ---> Optional when you need to move some functions out of the component file to keep things clean.
  utils/ ---> JS files that are globally needed, helper functions, etc.


    구성품

    Your Frontend Components will most likely be grouped into 2 kinds, presentational and connected components.

    기억할 가치가 있는


  • 기능적 구성요소를 끝까지 사용하도록 노력하세요. 클래스 구성 요소와 수많은 수명 주기 메서드를 처리하지 않아도 됩니다.
  • 기능 폴더에서 모든 구성 요소를 내보내는 색인 파일이 있으면 가져오기 및 내보내기를 구성하는 데 도움이 됩니다.

    • 프리젠테이션 구성 요소

    • Have no dependencies on the rest of the application.
    • Values and callbacks are passed into these via props.

    Example:

    ComponentName/
  ComponentName.tsx ---> Using named exports e.g `export const ComponentName = () => {}` Always keep this file as simple as possible
  Styles.tsx ---> A case for using styledComponents, all created elements will be stored here, exported using named exports
  index.ts ---> exports { ComponentName } from './Componentname'
  utils.ts ---> Optional when you need to move some functions out of the component file to keep things clean.

    export const PresentationComponent = ({ prop1, props2 ...propN }) => (
  <div>Show something</div>
);

    연결된 구성 요소

    • are responsible for retrieving data.
    • are aware of the store and be connected to it.
    • provide data to other components.
    • are responsible for dispatching actions.
    • grab data from store and then passes that data down to its children as props.

    Example:

    ComponentName/
  ComponentName.tsx ---> Using named exports e.g `export const ComponentName = () => {}` Always keep this file as simple as possible
  Styles.jsx ---> A case for styledComponents, all created elements will be stored here, exported using named exports
  actions/ ---> handles all Async events, and certain Events that needs to be seperated from the components.
    store/ reducers/ etc
    api|hooks/
  index.js ---> exports { ComponentName } from './Componentname'
  utils.js ---> Optional when you need to move some functions out of the component file to keep things clean.

    스타일링 구성 요소

    Because I've been a making a case for using styled components, we will like to keep these clean and away from jsx logic. All created styled components will be inside an Styles.js file inside the component folder.

    Example:

    // Styles.js
import styled from "styled-components";

export const Header = styled("div")`
  display: flex;
  flex-direction: column;
  width: 500px;
  height: 200px;
`;

export const Footer = styled("div")`
  display: flex;
  flex-direction: column;
  width: 500px;
  height: 200px;
`;
export const LeftMenu = styled("div")`
  display: flex;
  flex-direction: column;
  width: 500px;
  height: 200px;
`;

    백엔드와 상호 작용

    All backend related actions should be in the actions folder within each components directory. see Connected Components 위

    상태 공유

    There's a couple of options for this and I see most teams now are leaning towards React Context for React applications,
    other worthy mentions include:
    Redux, VueX, Mobx.

    Same philosophy applies regardless of the state library employed.

    Actions/
  reducers/

    This writeup is highly opinionated on my experience but a lot of teams both small and large have similar approach to handling their frontend applications.

    Let me know if you find this useful or have questions or share how you've been able to structure your frontend applications at work.

     Photo by Simone Hutsch 온 Unsplash
    Unity에서 Texture2D로 그리기
    Laravel로 서명된 URL

    좋은 웹페이지 즐겨찾기

    개발자 우수 사이트 수집

    개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
    best100-homepage