フロントエンドアプリケーションのスケーリング

10040 ワード
frontend architecture react scaling テキストリンク
あなたのフロントエンドアプリケーションを構築することは、製品とコードベースが成長するにつれてトリッキーになることができます.このポストでは、私はすべての種類のフロントエンドプロジェクトのサイズのための作業ソリューションに発見したものを共有します.このガイドラインは、duck pattern .
アヒルの全体のアイデアは、それがモジュラー、変更を簡単にスケーラブルで、簡単にデコンストラクションできるようにする方法で一緒に一見関係のあるファイルをグループ化することですし、必要な場合は、状態ライブラリなどの周りの技術を移動します.
アヒルは、彼らがグループにいるとき、最小の大騒ぎで最も感じる最も活発な、最もすばらしい動物です.
そのコアのアヒルパターンは、彼らと一緒に仕事をするためにユニットとして一緒に働く小さなファイルを配置することについてです.下記ガイドラインを参照
  • 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
    「機能最初」は、あなたのアプリが含む主要な機能の後、あなたのトップレベルフォルダを命名することを指します.
    それぞれの新機能は、独自のフォルダーが付属しているので、このテクニックはかなり良いスケール.
    任意の機能に関連付けられていないファイルを持つことができますし、共通/共有/コアE . T . Cを呼び出します.

    関数ファースト❌


    Components/
  Login.tsx
  Signup.tsx
Containers/
  Login.tsx
store/
  reducers.ts
  actions.ts
    "function first "は、ファイルの目的の後にトップレベルのフォルダを命名することを指します.
    これまでのところ、コンテナ、コンポーネント、アクション、減速機などがあります.
    これはまったくスケールにならない.
    ファイルは、あなたのプログラムが進化し、追加機能が追加されると同じディレクトリに追加されます.
    問題はまた、一緒にフォルダを結ぶことが含まれます.
    プログラム内の単一のフローは、ほぼ確実にすべてのディレクトリからファイルを編集する必要があります.
    “機能の最初の”アプローチを使用して、我々のような一般的なプロジェクトの構造を生成することができます
    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 on Unsplash
    ポインタと配列の関係
    [初級]Python出力