James Tsang

James Tsang

A developer.
github
twitter
tg_channel

ARTS 打卡第 1 天

A:617. 合并二叉树

アルゴリズムの基礎はかなり弱く、何度も実行してやっと通りました~

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 はもはや利点ではなく、ベースライン、通常の方法です。他のフレームワークにも似たようなものがありますが、より速く、より簡単に使用および記述できます。
  • レンダリングを微細なレベルで管理する必要はありません:たとえば、useMemouseCallbackの違い、useEffectの依存関係とライフサイクルの理解など。他のフレームワークではこれらを心配する必要はありません。それらはよりスマートであり、更新する必要のないものを継続的に更新するのではなく、値のみを更新します。
  • 大規模で複雑なアプリケーションの処理はもはや焦点ではありません:React は大規模で複雑なアプリケーションに対するフロントエンドの最適な、唯一の、さらには最初の解決策ではありません。それは単一のパラダイムの多くの可能なバージョンの 1 つであり、また古いバージョンでもあります。他の現代の競合フレームワークも同じ問題に対処できます。
  • サーバーサイドレンダリングは特別ではありません:React 以外のほとんどのプレーヤーもサーバーサイドレンダリングをサポートしています。
  • 双方向データバインディングは難しくも悪くもありません:React は単方向のデータフローなので、フォームの使用が面倒です。双方向のデータフローでは、これらの問題はありませんし、長い間のイテレーションで引き起こされるいくつかの問題も解決されています。
  • スタイルの処理は非常に簡単です:React のスタイルにはエレガントなソリューションが組み込まれていませんが、Vue や Svelte では、この問題は組み込まれています。それらにはコンポーネントレベルのスコープがあり、React で使用できるソリューションも互換性があります。
  • フレームワークを学ぶのはもはや難しくありません:React の状態管理、プロパティ、ネスト、ライフサイクル、フック、JSX などの学習は友好的ではありません。現代の新しいフレームワークはもっと簡単に学べるようになりました。
  • 著者は Svelte と Vue という 2 つのコンパイル時フレームワークを推奨しています。

T:CodeBox

Python の隔離されたサンドボックス実行環境で、ChatGPT Code Interpreter を実装するために使用できます。

S:「最高学以致用法」を読んでのメモリー

出力と入力の比率は、最適な場合は 70% 対 30% に制御すべきです。出力こそが「効果的な」学習です。入力だけでは学ぶことはありませんし、覚えることもできません。


参考文献:

  1. ARTS 打卡活动
読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。