Zenn
Closed13

2024/2読んだ記事まとめ

kzk4043kzk4043

https://overreacted.io/the-two-reacts/

クライアントとサーバどっちでReact処理するかって話？

any direct manipulation (such as dragging a slider, switching a tab, typing into a post composer, clicking a like button, swiping a card, hovering a menu, dragging a chart, and so on) would feel broken if it didn’t reliably provide at least some instant feedback.

ページ遷移とかちょっと待つものだとユーザが理解してるものもあるが、SliderをドラッグするとかはすぐにFBしなきゃいけない。

対して、サーバ側で完結できる処理もあるよね

kzk4043kzk4043
  • UI = f(state) where state is client-side, and f runs on the client. This approach allows writing instantly interactive components like <Counter />. (Here, f may also run on the server with the initial state to generate HTML.)
  • UI = f(data) where data is server-side, and f runs on the server only. This approach allows writing data-processing components like <PostPreview />. (Here, f runs categorically on the server only. Build-time counts as “server”.)
kzk4043kzk4043

でも実際はUI = f(data, state)って感じで両方の場合が多いよね。この2つを意識せずに実装できないかな…？っていうことなのかな…？たぶんRSC文脈だと思うのだが（ちょっと違うかも）

kzk4043kzk4043

https://gomakethings.com/harmful-complexity-using-react-for-static-content/

  • Using over-engineered tooling (like React) for simple, mostly static websites.
  • Using too little tooling for large, interactive, data-driven UI.

銀の弾丸はないからサイト特性に応じて使い分けないとねみたいな話か？

kzk4043kzk4043

If your site is mostly static content, React is actively harmful to both the people who use it and the developers who have to work on an maintain it.

staticなサイトでReact使っても誰も幸せにならないよ。
全部jsでやるわけで、遅いし、作る人はHTML/CSSをないがしろにしがち、みたいな論調か？

kzk4043kzk4043

Static sites should be (mostly) static #

SSG(SSR)使おうよ。
WebComponentsとか使って、アイランドアーキテクチャ的な考えを使うのがいいんちゃう？みたいなことかな？

kzk4043kzk4043

メルマガの整理がしたい…いっぱい来すぎてさばけない

  • 週
    • 全体系
      • Codrops
      • Medium Weekly Digest
      • daily.dev
      • Qiita
    • トピック限定
      • React Status
      • CSS Weekly
      • js Weekly
      • Node Weekly
      • Front-End Front
  • 月？
    • Deno News
kzk4043kzk4043

目的

  • 変化の早いフロント領域の最先端の空気を感じておくこと
    • それによって常に現行技術スタックの検証を行うこと（最先端というのは現行に対する問題意識から発生してくるので、立ち返って現行の問題を露出できるのでは。例えばSPA全盛時代からMPAへの揺り戻し起きてるよね、的な。）

目的外

  • 案件に直接関与する知識は、直接検索によって得る想定

使い方の想定

  • 全てを見るのは無理なので、各メルマガの要約はざっと見て概要を掴む
  • まとめとか概念的な話とかそういうのは記事の中身を見たい気持ち
  • 取れても1日30分くらいだと思う。1時間は取れない。週末はちょっと多めに取れるかもだが…週合計4〜5時間
    • ということはちゃんと読む記事はせいぜい5くらいか？
    • 一旦ストックしといて、選別して読んだほうがいいか？→あとで読むかしら
      • 平日は概要にとどめて、週末に選別して読む？→これはアリかもしれない。それでよければ電車とかでも見れる。ストックして忘れない仕組みが必要か。なんかサービスあるかな？つくる？
        • Chrome拡張的な感じで各ページで追加ボタンおしたら勝手に追加していって、どこかに一覧化できる的な
        • 一旦ZennにURL貯めるか？
        • そうなってくると一週間ごとにスクラップ立てる感じになるのか？大丈夫かしら。まあいいか
kzk4043kzk4043
  • 週
    • 全体系 → 全体系多すぎなので絞る
      • Medium Weekly Digest → ちょっと数が多いのと、要約がない。消すか
      • daily.dev → 要約なし。Daily.devに1回飛ぶのがうざい。記事数的にはちょうどいいっちゃいいが…消すか。英語系全体も欲しいのはほしいのだが。。
      • Qiita → 日本語系は貴重なので残す
    • フロント
      • Codrops（週2） → 記事要約あり。内容も興味あり。残すか？
      • Front-End Front → ちょっと内容薄いので削除
    • トピック限定
      • React Status → フロントといえばなので残す。要約ちゃんとしてくれてるし。
      • CSS Weekly → ちょっと迷うな…codropsで網羅される気もする
      • js Weekly → フロントといえばなので残す。要約ちゃんとしてくれてるし。
      • Node Weekly → フロントといえばなので残す。要約ちゃんとしてくれてるし。
  • 月？
    • Deno News → 月イチくらいだし残しとく
このスクラップは2024/02/04にクローズされました