React で最も複雑なことは何だと思いますか?再レンダリングしますか?コンテクスト？ポータル？同時実行性?

いいえ。

React の最も難しい部分は、その周囲にある非 Reactすべてです。 「上に挙げたものはどのように機能するのですか?」という質(zhì)問に対する答えです。やり方は簡単です。アルゴリズムに従ってメモを取るだけです。結(jié)果は決定的であり、常に同じになります (正しく追跡した場合)。それは単なる科學(xué)と事実です。

しかし、「コンポーネントを優(yōu)れたものにするものは何ですか?」についてはどうでしょうか。または「… (何か) を?qū)g裝する正しい方法は何ですか?」あるいは「ライブラリを使用するべきですか、それとも獨自のソリューションを構(gòu)築すべきですか?」ここでの事実上正しい唯一の答えは、「狀況による」です。たまたまそれは最も役に立たないものです。

新しい記事用に、これよりも優(yōu)れたものを見つけたいと思いました。しかし、この種の質(zhì)問には単純な答えや普遍的な解決策があるはずがないため、この記事は「これが答えです。常にそうしてください」というよりは、私の思考プロセスを詳しく説明するものになりました。これからも役立つことを願っています。

それでは、機能をアイデアから運用可能なソリューションに移行するには何が必要でしょうか?簡単なモーダルダイアログを?qū)g裝して見てみましょう。それについて何が複雑になるでしょうか? ?

ステップ 1: 最も単純な解決策から始める

「スパイク」とも呼ばれるものから始めましょう。これは、潛在的なソリューションを探索し、さらなる要件を収集するのに役立つ最も単純な実裝です。モーダルダイアログを?qū)g裝していることはわかっています。次のようなきれいなデザインがあると仮定しましょう:

ダイアログは基本的に、ボタンのようなものがクリックされたときに表示される畫面上の要素です。まさにそこから始めます。

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

狀態(tài)、クリックを待機するボタン、および狀態(tài)が true のときに表示される將來のダイアログ。ダイアログには「閉じる」アクションも必要です:

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

これには「背景」もあります。これは、コンテンツをオーバーレイし、クリックされるとモーダルが消えるトリガーとなるクリック可能な半透明の div です。

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

全員で:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

私は通常、早い段階で適切なスタイルを追加します。実裝している機能が想定どおりの外観で畫面に表示されるのを見ると、考えるのに役立ちます。さらに、機能のレイアウトを通知することもできます。これはまさにこのダイアログで行われることです。

すぐに背景の CSS を追加しましょう - これは特別なことではなく、畫面全體を占める位置: 固定の div 上の半透明の背景だけです:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

ダイアログは畫面の中央に配置する必要があるため、少し興味深いものになります。もちろん、CSS でこれを?qū)g現(xiàn)する方法は 1001 通りありますが、私のお気に入りでおそらく最も簡単な方法は次のとおりです:

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

レイアウトの制約から逃れるために「固定」位置を使用し、左と上に 50% を追加して div を中央寄りに移動し、50% だけ元に戻します。左と上は畫面に対して相対的に計算され、変換は div 自體の幅/高さに相対的に行われるため、結(jié)果として畫面の幅や幅に関係なく中央に表示されます。

このステップの CSS の最後の部分は、ダイアログ自體と「閉じる」ボタンを適切にスタイル設(shè)定することです。ここではコピー＆ペーストしません。実際のスタイルはそれほど重要ではありません。例を見てください:

ステップ 2: 立ち止まって質(zhì)問し、考える

機能の大まかな実裝ができたので、今度はそれを「実際」にします。そのためには、ここで正確に何を、誰のために解決しようとしているのかを詳細に理解する必要があります。技術(shù)的に言えば、何かをコーディングする前を理解する必要があるため、多くの場合、このステップはステップ 1である必要があります。

このダイアログは、できるだけ早く実裝する必要があり、投資家に一度見せたら二度と使用しないプロトタイプの一部ですか?それとも、npm およびオープンソースで公開する予定の汎用ライブラリの一部なのでしょうか?それとも、5,000 人規(guī)模の組織が使用するデザイン システムの一部なのでしょうか?それとも、それは 3 人の小さなチームのための內(nèi)部ツールの一部であり、他には何もないのでしょうか?それとも、TikTok などで働いていて、このダイアログはモバイルでのみ利用できる Web アプリの一部になるのでしょうか?それとも、政府専用のアプリを作成する代理店で働いているのでしょうか?

これらの質(zhì)問に答えることで、コーディングに関して次に何をすべきかの方向性が決まります。

一度使ってみるプロトタイプなら、もう十分かもしれません。

ライブラリの一部としてオープンソース化する場合は、世界中の開発者が使用して理解できる非常に優(yōu)れた汎用 API、多くのテスト、優(yōu)れたドキュメントが必要です。

5,000 人規(guī)模の組織の設(shè)計システムの一部であるダイアログは、組織の設(shè)計ガイドラインに準拠する必要があり、リポジトリに取り込まれる外部依存関係が制限される場合があります。したがって、npm install new-fancy-tool を?qū)g行するのではなく、多くのことを最初から実裝する必要があるかもしれません。

政府のために構(gòu)築する機関の対話は、おそらく世界で最もアクセスしやすく、規(guī)制に準拠した対話である必要があります。そうしないと、政府機関は政府との契約を失い、破産する可能性があります。

などなど。

この記事では、このダイアログが、世界中から毎日何千人ものユーザーが集まる既存の大規(guī)模商用 Web サイトの、現(xiàn)在進行中の新たな再設(shè)計の一部であると仮定します。再設(shè)計が進行中であるため、ダイアログを含む唯一のデザインは次のとおりです:

殘りは後ほど、デザイナーたちは忙殺されています。また、私は単一のプロジェクトのために雇われた外部請負業(yè)者ではなく、再デザインを行って今後のウェブサイトの保守を行う常設(shè)チームの一員です。

この場合、この寫真だけがあり、會社の目標について知っていれば、合理的な仮定を立てて対話の 90% を?qū)g行するのに十分な情報が得られます。殘りの 10% は後で微調(diào)整できます。

これらは、上記の情報に基づいて私が立てることができる仮定です:

• 既存の Web サイトには毎日世界中から何千人ものユーザーがアクセスするため、少なくともダイアログが大畫面とモバイル畫面の両方、およびさまざまなブラウザーで動作することを確認する必要があります。理想的には、確実に既存の分析をチェックする必要がありますが、これはかなり安全な方法です。

• 複數(shù)の開発者がこのためのコードを作成しており、そのコードは存続します。この Web サイトは大規(guī)模で、すでに何千人ものユーザーがいます。それは投資家にとって簡単なプロトタイプではありません。したがって、コードが読みやすく、API が意味をなし、使いやすく保守しやすく、明らかな不法行為がないことを確認する必要があります。

• その會社は自社のイメージと Web サイトの品質(zhì)を重視しています。そうでない場合、そもそもなぜ再デザインを行うのでしょうか? (ここでは肯定的な意図があると仮定しましょう?)。つまり、一定レベルの品質(zhì)が期待されており、たとえそれが現(xiàn)在の設(shè)計に含まれていないとしても、一般的なシナリオやエッジケースを事前に考えて予測する必要があります。

• 多くのユーザーは、Web サイトとの対話にマウスのみを使用するユーザーが全員ではないことを意味していると思われます。このダイアログは、キーボード操作や、場合によってはスクリーン リーダーなどの支援技術(shù)によっても利用できる必要があります。

• 大規(guī)模な既存のコードベース (再設(shè)計です、覚えておいてください!) は、この機能にもたらすことができる外部依存関係に制限がある可能性があることを意味します。特に大規(guī)模で古いコードベースでは、外部依存関係にはコストがかかります。この記事では、外部ライブラリを使用できると仮定しますが、これには十分な根拠が必要です。

• 最後に、さらに多くのデザインが登場するため、デザインとユーザーの観點からそれがどのような方向に進むかを予測し、コードが早い段階でそれを処理できることを確認する必要があります。

ステップ 3: モーダル ダイアログ API を確立する

要件が分かり、妥當な推測ができたので、実際のダイアログ コンポーネントを作成できます。まず、このコードから:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

ダイアログ部分を再利用可能なコンポーネントに抽出する必要があります。実裝すべきダイアログベースの機能がたくさんあります。

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

ダイアログには onClose プロパティがあり、「閉じる」ボタンまたは背景がクリックされたときに親コンポーネントに通知します。親コンポーネントは狀態(tài)を保持し、次のようにダイアログをレンダリングします。

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

それでは、デザインをもう一度見て、ダイアログについてもう少し考えてみましょう:

ダイアログにはアクション ボタンを備えた「フッター」部分が明らかに存在します。おそらく、これらのボタンには、1 つ、2 つ、3 つ、左揃え、右揃え、間にスペースを入れるなど、たくさんのバリエーションがあるでしょう。また、このダイアログには ヘッダー がありませんが、ヘッダーのあるダイアログは非常に一般的なパターンです。ここには、確認テキストからフォーム、インタラクティブなエクスペリエンス、誰も読まない非常に長い「利用規(guī)約」のスクロール可能なテキストまで、完全にランダムなコンテンツを含む コンテンツ エリアが必ず存在します。

最後に、サイズです。デザイン內(nèi)のダイアログは非常に小さく、単なる確認ダイアログです。大きなフォームや長いテキストはそこには収まりません。したがって、ステップ 2 で収集した情報を考慮すると、ダイアログのサイズを変更する必要があると考えて間違いありません?，F(xiàn)時點では、デザイナーがデザイン ガイドラインを持っている可能性が高いことを考慮すると、ダイアログには「小」、「中」、「大」の 3 つのバリエーションがあると想定できます。

これはすべて、ModalDialog に props が必要であることを意味します。フッターとヘッダーは ReactNode を受け入れる通常の props になり、サイズは単なる文字列の結(jié)合になり、メイン部分としてコンテンツ領(lǐng)域が入ります。子供たち:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

プロパティから得られる追加の className を使用してダイアログのサイズを制御します。ただし、実際には、リポジトリで使用されるスタイリング ソリューションに大きく依存します。

しかし、このバリアントでは、ダイアログが非常に柔軟であり、ほとんどすべてのものをどこでも使用できます。たとえば、フッターにはほとんどの場合、ボタンが 1 つか 2 つあるだけで、それ以上は何も期待できません。そして、これらのボタンは Web サイト全體のどこにでも一貫して配置される必要があります。それらを整列させるラッパーが必要です:

.backdrop {
  background: rgba(0, 0, 0, 0.3);
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

コンテンツについても同様です。少なくとも、コンテンツの周囲にある程度のパディングとスクロール機能が必要です。また、ヘッダーにはテキストのスタイルが必要になる場合があります。したがって、レイアウトは次のようになります:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

しかし、殘念ながら、それを保証することはできません。ある時點で、ボタン以外の何かをフッターに追加したいと思う人がいる可能性が非常に高いです。または、一部のダイアログには、販売されている背景にヘッダーが必要になる場合があります。または、コンテンツにパディングが必要ない場合もあります。

私がここで言いたいのは、いつかヘッダー/コンテンツ/フッター部分のスタイルを設(shè)定できるようにする必要があるということです。そしておそらく予想よりも早いでしょう。

もちろん、その構(gòu)成を props とともに渡し、headerClassName、contentClassName、footerClassName などの props を持たせることもできます。場合によっては、実際には大丈夫かもしれません。しかし、素晴らしい再デザインのための素晴らしいダイアログのようなものについては、もっと良くできるはずです。

この問題を解決する非常に優(yōu)れた方法は、次のようにヘッダー/コンテンツ/フッターを獨自のコンポーネントに抽出することです。

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

そして ModalDialog コードをラッパーなしのコードに戻します:

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

こうすることで、親アプリでダイアログ パーツのデフォルトのデザインを使用したい場合は、これらの小さなコンポーネントを使用します。

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

そして、完全にカスタムなものが必要な場合は、ModalDialog 自體をいじらずに、獨自のカスタム スタイルを持つ新しいコンポーネントを?qū)g裝します。

.backdrop {
  background: rgba(0, 0, 0, 0.3);
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

さらに言えば、ヘッダーとフッターのプロップももう必要ありません。 DialogHeader と DialogFooter を子に渡すだけで、ModalDialog をさらに簡素化し、どこでも一貫したデザインを保ちながら、同じレベルの柔軟性を備えたさらに優(yōu)れた API を?qū)g現(xiàn)できます。

親コンポーネントは次のようになります:

.dialog {
  position: fixed;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

ダイアログの API は次のようになります:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <>
          <div
            className="backdrop"
            onClick={() => setIsOpen(false)}
          ></div>
          <div className="dialog">
            <button
              className="close-button"
              onClick={() => setIsOpen(false)}
            >
              Close
            </button>
          </div>
        </>
      ) : null}
    </>
  );
}

今のところかなり満足しています。デザインに必要なあらゆる方法で拡張できる十分な柔軟性を備えていますが、アプリ全體に一貫した UI を簡単に実裝できるほど明確で賢明でもあります。

これが実際に試してみるサンプルです:

ステップ 4: パフォーマンスと再レンダリング

Modal の API が十分に適切な形になったので、私が実裝した明らかなフットガンに取り組むときが來ました。私の記事を十分に読んだ人なら、おそらく「何をやってるの？ 再レンダリングだ??！」と大聲で叫んだことがあるでしょう。最後の10分間？そしてもちろん、あなたは正しいです:

const ModalDialog = ({ onClose }) => {
  return (
    <>
      <div className="backdrop" onClick={onClose}></div>
      <div className="dialog">
        <button className="close-button" onClick={onClose}>
          Close
        </button>
      </div>
    </>
  );
};

ここの Page コンポーネントには狀態(tài)があります。モーダルが開いたり閉じたりするたびに狀態(tài)が変化し、コンポーネント全體とその內(nèi)部のすべてが再レンダリングされます。確かに「時期尚早の最適化は諸悪の根源」であり、実際に測定する前にパフォーマンスを最適化しないでください。この場合、従來の通念を無視しても問題ありません。

理由は 2 つあります。まず、アプリ全體に多數(shù)のモーダルが散在することは事実としてわかっています。これは、誰も使用しない 1 回限りの隠された機能ではありません。したがって、誰かがこのような API を使用して、あるべきではない場所に狀態(tài)を配置する可能性は非常に高いです。第 2 に、そもそも再レンダリングの問題の発生を防ぐのに、それほど時間も労力もかかりません。たった 1 分間の作業(yè)で、ここでのパフォーマンスについてはまったく考える必要がなくなります。

私たちがする必要があるのは、狀態(tài)をカプセル化し、「非制御コンポーネント」の概念を?qū)毪工毪长趣坤堡扦埂?br>

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

BaseModalDialog は以前のダイアログとまったく同じですが、名前を変更しただけです。

次に、ダイアログをトリガーするコンポーネントをトリガー プロップとして渡します。

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

ページ コンポーネントは次のようになります:

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

ページ內(nèi)に狀態(tài)が存在することはなくなり、潛在的に危険な再レンダリングもなくなりました。

ほとんどの場合、ダイアログを表示するにはユーザーが何かをクリックする必要があるため、このような API はユースケースの 95% をカバーするはずです。まれに、ショートカット上やオンボーディングの一部としてダイアログを獨立して表示する必要がある場合でも、BaseModalDialog を使用して狀態(tài)を手動で処理できます。

ステップ 5: 特殊なケースとアクセシビリティへの対処

ModalDialog コンポーネントの API は React の観點から見ると非常に堅牢ですが、仕事はまだ終わっていません。ステップ 2 で収集した必需品を考慮すると、さらにいくつかの問題を修正する必要があります。

問題 1: トリガーを追加のスパンにラップしています。場合によっては、ページのレイアウトが崩れる可能性があります。何とかしてラッパーを取り除く必要があります。

問題 2: 新しいスタッキング コンテキストを作成する要素內(nèi)でダイアログをレンダリングすると、一部の要素の下にモーダルが表示されます?，F(xiàn)在のようにレイアウト內(nèi)で直接レンダリングするのではなく、ポータル內(nèi)でレンダリングする必要があります。

問題 3: 現(xiàn)時點では、キーボードへのアクセスが非常に悪いです。適切に実裝されたモーダル ダイアログが開くと、フォーカスが內(nèi)部に移動するはずです。閉じると、ダイアログをトリガーした要素にフォーカスが戻ります。ダイアログが開いているとき、フォーカスは內(nèi)部に「トラップ」され、外部の要素はフォーカス可能であってはなりません。 ESC ボタンを押すとダイアログが閉じます?，F(xiàn)時點では、これはどれも実裝されていません。

問題 1 と 2 は少し面倒ですが、比較的早く解決できます。ただし、問題 3 を手動で行うのは非常に面倒です。さらに、これは確実に解決された問題です。どこにいても、すべてのダイアログにこの機能が必要です。

「自分でやるには大変な苦労」「確実に解決された問題のように見える」という組み合わせがあれば、私は既存のライブラリを探すことになります。

すでに行ったすべての事前作業(yè)を考慮すると、適切なものを選択するのは簡単です。

Ant Design やマテリアル UI などの既存の UI コンポーネント ライブラリを選択し、そこからダイアログを使用することもできます。しかし、再設(shè)計でそれらが使用されない場合、必要なものに合わせて設(shè)計を調(diào)整することは、解決するよりもさらに多くの苦痛をもたらすことになります。したがって、この件に関しては即座にノーです。

Radix や React Aria などの「ヘッドレス」UI ライブラリのいずれかを使用できます。これらは狀態(tài)やトリガーなどの機能とすべてのアクセシビリティを?qū)g裝しますが、設(shè)計は消費者に委ねられます。 API を確認しながら、ダイアログを手動でトリガーしたい場合に本當に必要な場合 (実際にトリガーする必要がある場合)、ダイアログの狀態(tài)を制御できるかどうかを再確認する必要があります。

何らかの理由でヘッドレス ライブラリを使用できない場合は、少なくともフォーカス トラップ機能を処理するライブラリを使用しようとします。

記事のために、必要なライブラリを何でも持ち込めると仮定しましょう。この場合、Radix を使用します。これは非常に使いやすく、ダイアログの API は既に実裝したものと非常によく似ているため、リファクタリングは簡単です。

ダイアログ自體の API を少し変更する必要があります:

export default function Page() {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <>
      <button onClick={() => setIsOpen(true)}>
        Click me
      </button>
      {isOpen ? (
        <div className="dialog">some content</div>
      ) : null}
    </>
  );
}

以前とほぼ同じです。ただし、どこでも div の代わりに、Radix プリミティブを使用します。

制御されていないダイアログの使用法はまったく変わりません:

<button
  className="close-button"
  onClick={() => setIsOpen(false)}
>
  Close
</button>

制御されたダイアログはわずかに変更されます - 條件付きレンダリングの代わりに props を渡す必要があります:

<div
  className="backdrop"
  onClick={() => setIsOpen(false)}
></div>

以下の例を確認し、キーボードを使用して操作してみてください。すべてが必要なとおりに機能します。なんて素晴らしいことでしょう?

おまけに、Radix はポータルの問題も処理し、トリガーをスパンでラップしません。もう解決すべきエッジケースはないので、最後のステップに進むことができます。

ステップ6: 最終磨き

この機能はまだ完成していません! ?ダイアログの見た目も感觸もかなり安定したものになったので、現(xiàn)段階では実裝に大きな変更を加えるつもりはありません。しかし、私が解決しているユースケースにとって「完璧な」ダイアログとみなされるには、まだいくつかの點が必要です。

1 つ: デザイナーがまだ行っていない場合、最初に私に依頼するのは、ダイアログが開くときに微妙なアニメーションを追加することです。それを予測して、React でアニメーションを?qū)g行する方法を覚えておく必要があります。

Two: 小さな畫面でも適切に見えるように、ダイアログに max-width と max-height を追加する必要があります。そして、非常に大きな畫面でどのように見えるか考えてみましょう。

Three: モバイル上でダイアログがどのように動作するかについてデザイナーと話し合う必要があります。おそらく、ダイアログのサイズに関係なく、畫面の大部分を占めるスライドイン パネルにするよう依頼されるでしょう。

4 つ: 少なくとも DialogTitle コンポーネントと DialogDescription コンポーネントを?qū)毪工氡匾ⅳ辘蓼?。Radix はアクセシビリティ目的でそれらを使用するよう求めます。

5: テスト!このダイアログは存続し、他の人によって維持されるため、この場合テストはほぼ必須です。

そしておそらく私が今忘れているその他の小さなことはたくさんありますが、後で取り上げます。ダイアログのコンテンツの実際のデザインを?qū)g裝することは言うまでもありません。

さらにいくつかの考え

上記の「ダイアログ」を「SomeNewFeature」に置き換えると、ほぼすべての新しいものを?qū)g裝するために私が使用するアルゴリズムがこれになります。

ソリューションを迅速に「スパイク」→機能の要件を収集→機能させる→パフォーマンスを向上させる→完成させる→完璧にする

これまでに何百回も実裝してきた実際のダイアログのようなものについては、頭の中で最初のステップを 10 秒以內(nèi)に実行し、すぐにステップ 2 から始めます。

非常に複雑で未知のものの場合、ステップ 1 が長くなる可能性があり、すぐにさまざまなソリューションやライブラリを探索する必要があります。

正確には未知ではなく、単に「実行する必要がある通常の機能」である場合は、探索するものが何もない可能性があるため、ステップ 1 をスキップする可能性があります。

特に「アジャイル」環(huán)境では、要件が段階的に提供され、頻繁に変更される直線というよりスパイラルになることが非常に多く、私たちは定期的に最初の 2 つのステップに戻ります。

---

この種の記事がお役に立てば幸いです! ??このようなコンテンツをもっと増やしたい場合、または通常の「物事の仕組み」に関する內(nèi)容を希望する場合は、お知らせください。

そして、このプロセスが皆さんの頭の中でどう違うのかを聞くのを楽しみにしています?

---

元々は https://www.developerway.com で公開されました。ウェブサイトにはこのような記事が他にもありますか?

Advanced React ブックを読んで、React の知識を次のレベルに引き上げてください。

ニュースレターを購読したり、LinkedIn で接続したり、Twitter でフォローしたりすると、次の記事が公開されたらすぐに通知を受け取ることができます。

---

ところで、最後にもう 1 つ: 新しいプロジェクトをすぐに開始する予定で、デザイナーがいない場合と、説明したようにデザイン エクスペリエンスを磨く時間がない場合 - 私は最近、新しいプロジェクトの実裝に何時間も費やしました。この場合の UI コンポーネントのライブラリ。コピー＆ペースト可能なコンポーネントと共通パターン、Radix と Tailwind、ダーク モード、アクセシビリティ、すぐに使えるモバイル サポートが備わっています。上記の完璧なモーダル ダイアログが含まれています。 ?

試してみましょう: https://www.buckets-ui.com/

以上が実存的な React の質(zhì)問と完璧なモーダル ダイアログの詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。