Der Lebenszyklus existiert in React mit Hooks nicht

ずっと昔、クラスで React を使用していたのを覚えていますか?

当時、私たちはライフサイクル メソッド、つまり特定の瞬間に実行されるコールバックを受け入れるクラスのメソッドという概念を持っていました。大きな 3 つ: マウント時、更新時、アンマウント時。

古いけどゴールドクラス

これは重要でした。クラス コンポーネントでは、返される JSX は render メソッドで作成され、状態はコンポーネントの this に付加され、アプリ開発者は特定の瞬間にアクションを実行する方法を知る方法が必要でした。私たちはコンポーネントの寿命について次のような考えを持っていました:

• ComponentDidMount は、コンポーネントが初めてレンダリングされて DOM に要素を追加する瞬間であり、接続や API リクエストなどの副作用が開始される瞬間です。
• shouldComponentUpdate を使用すると、次のプロパティと状態を比較し、再レンダリングをスキップできるかどうかを定義するブール値を返すロジックを手動で設定できます。
• ComponentDidUpdate は、状態または props が変更された瞬間であり、render メソッドを再度呼び出し、ID の差異に対する調整変更を実行して DOM に適用します。状態を新しい props と同期し、ロジック処理を行うのに適しています。
• ComponentWillUnmount は、React が DOM から要素を削除するときであり、内容をクリーンにしてメモリ リークを回避するのに適した場所でした。

そしてもちろん、React 状態の更新に接続しない外部データを使用している場合に、再レンダリングを手動でトリガーできる、forceUpdate などの重要な API がありました。

概念的なレベルでは、アプリのフローを実行するより直接的な方法があります。ライフサイクル メソッドは DOM 要素の同様のライフ サイクルに従い、自分でメモや ForceUpdate を実行でき、状態の同期がロジックを実行するデフォルトの方法でした。

この直接性は単純さとみなされ、これらの概念を学ぶのはリアクティブ モデルに比べて簡単でした。しかしその後、フックが登場し、すべてが変わりました。

名前のない反応性

移行は混乱を招きました。まず、開発者が抱いていた React モデルの概念的なビジョンを簡単に維持するために、多くのコミュニケーションがフック モデルの類似点を示そうとしました。 3 つの主要なライフ サイクル メソッドを実現するために、useEffect を使用した回避策が示されました。

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);

したがって、フックを使用して作成された新しい React コードのほとんどはこの考え方に従っており、状態の同期を開始するのは自然なプロセスでした。ライフサイクル メソッドの同じ考え方を維持するために、setState を呼び出して再レンダリング プロセスをトリガーする場所になりました。

何が問題ですか?

状態の同期が問題になり、useEffect の間違った使用法が問題になり、2 回の再レンダリングが問題になり、再レンダリングの多さが問題になり、パフォーマンスが問題になりました。

It’s a little bit confusing this step from React, at least for me. Because, the move to hooks was a move to a reactive model, even if it’s a coarse-grained one. But the communication was that nothing really big changed. No content about the reactivity concepts and theory, even working for years with React, I just started to really understand reactivity reading Ryan Carniato’s blog posts about reactivity and solid.

Even knowing that useEffect had a misuse, I really didn’t understand why, and this lack of conceptual theory about reactivity makes committing mistakes with hooks so easy. useEffect became the most hated hook, being called “useFootgun” for some people. The point is, there is a conceptual confusion in React that expresses itself as all the issues with useEffect we see today.

useEffect issues are not the cause of the problem, but the consequence.

What about life cycle with hooks

So, this is the thing. There is no life cycle in the concept of reactivity.

You have a change, you react to it deriving and doing side effects. Effects are the consequence, not the cause. There is no state sync and no concepts of mount and unmount.

It should not matter if it is the first, the 10th or the last render before unmount, and the hooks don’t care for it, by the way, even useEffect.

Try it:

function EffectExample() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect', count);

    return () => {
      console.log('clean up', count);
    }
  }, [count]);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

You will see on your console both functions being executed on each state update. First the clean up one, and then the effect callback. If you are using useEffect with some state or prop to do a subscription, every time the dependencies changes, the clean up function will be called, and then the new callback, doing the subscription again, but with the new values.

You should look your app code as the React model simplified:

UI = fn(state)

If you have a component like this one:

function Example() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

what you really have, when you click on the button and adds +1 to the count, conceptually, is something like this:

// first render
<button>0</button> = fn({ count: 0 });
// button click - re-render
<button>1</button> = fn({ count: 1 });
// button click - re-render
<button>2</button> = fn({ count: 2 });
// button click - re-render
<button>3</button> = fn({ count: 3 });

Each click calls again the fn, with a new state, generating a new version of UI. The state should change by the action of the user or by an async value that should be made with async derivations.

This way you keep the clean idea:

• state transitions make a new fn call
• with the new state, you get the UI description
• if it’s different, update the screen.

A clean and consistent model.

it’s a matter of the renderer to care with adding, updating and removing elements from the screen. At the component level, what matters is:

• wenn sich der Zustand geändert hat
• ob die App die Benutzeraktionen verarbeiten kann
• die zurückgegebene Struktur im JSX.

Hooks und sein reaktives Modell sorgen dafür, dass sich React vom Browser entkoppelt, sodass sich der App-Code weniger darum kümmert, in welchem ​​Moment des Bildschirmrendering-Prozesses Sie sich befinden. Sie erzwingen keine Aktualisierungen und verwalten Memos nicht mehr nach Ihren eigenen Regeln. Dies ist weniger direkt für den App-Entwickler, aber direkter im Hinblick auf das Modell.

Jedes erneute Rendern generiert eine Struktur, React kümmert sich um den Rest.

Das obige ist der detaillierte Inhalt vonDer Lebenszyklus existiert in React mit Hooks nicht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!