アルゴリズムの基礎はかなり弱く、何度も実行してやっと通りました~
R:Things you forgot (or never knew) because of React
- React は早期にリリースされたため、一定の優位性を持ち、標準となりましたが、柔軟性と適応性にはいくつかの重大な欠点もあります。2013 年以降、React のすべての決定は、別の技術的負債の一層であり、競合他社にはこのような制約がありません。
- エコシステムに関する問題について:私たちはフレームワーク固有のパッケージだけが存在すると信じ込まされていますが、React はこの考え方を加速させ、何をするにも React のパッケージを見つけることになります。その結果、React のルール、状態管理、コンポーネントライフサイクルなどが持ち込まれ、このセットと互換性のないものはうまく機能しないか、便利ではありません。しかし、そうする必要はありません。すべては単なる JS であり、したがって、JS のものであればすべて取り込むことができるべきです。(もちろん、Svelte や Vue などのフレームワークにも同じことが言えますが、React が最も重いものであり、他のいくつかのフレームワークはより適応性があり、レンダリングライフサイクルなどの問題はありません。これらのフレームワークの共通の選択肢は Web コンポーネントを使用しています)。Preact の Signal はその例です。Preact 自体に使用されるものですが、他のどのフレームワークでも使用することができます。Web コンポーネントも同様で、React 以外のフレームワークと互換性があります。
- React Hooks は時代遅れです:Hooks はもはや利点ではなく、ベースライン、通常の方法です。他のフレームワークにも似たようなものがありますが、より速く、より簡単に使用および記述できます。
- レンダリングを微細なレベルで管理する必要はありません:たとえば、
useMemo
とuseCallback
の違い、useEffect
の依存関係とライフサイクルの理解など。他のフレームワークではこれらを心配する必要はありません。それらはよりスマートであり、更新する必要のないものを継続的に更新するのではなく、値のみを更新します。 - 大規模で複雑なアプリケーションの処理はもはや焦点ではありません:React は大規模で複雑なアプリケーションに対するフロントエンドの最適な、唯一の、さらには最初の解決策ではありません。それは単一のパラダイムの多くの可能なバージョンの 1 つであり、また古いバージョンでもあります。他の現代の競合フレームワークも同じ問題に対処できます。
- サーバーサイドレンダリングは特別ではありません:React 以外のほとんどのプレーヤーもサーバーサイドレンダリングをサポートしています。
- 双方向データバインディングは難しくも悪くもありません:React は単方向のデータフローなので、フォームの使用が面倒です。双方向のデータフローでは、これらの問題はありませんし、長い間のイテレーションで引き起こされるいくつかの問題も解決されています。
- スタイルの処理は非常に簡単です:React のスタイルにはエレガントなソリューションが組み込まれていませんが、Vue や Svelte では、この問題は組み込まれています。それらにはコンポーネントレベルのスコープがあり、React で使用できるソリューションも互換性があります。
- フレームワークを学ぶのはもはや難しくありません:React の状態管理、プロパティ、ネスト、ライフサイクル、フック、JSX などの学習は友好的ではありません。現代の新しいフレームワークはもっと簡単に学べるようになりました。
- 著者は Svelte と Vue という 2 つのコンパイル時フレームワークを推奨しています。
T:CodeBox
Python の隔離されたサンドボックス実行環境で、ChatGPT Code Interpreter を実装するために使用できます。
出力と入力の比率は、最適な場合は 70% 対 30% に制御すべきです。出力こそが「効果的な」学習です。入力だけでは学ぶことはありませんし、覚えることもできません。
参考文献: