Open8

記事まとめ

TimdaikTimdaik

ちょい昔の技術ブログを漁っては読むのが好きなんだけど、そういえばまとめていなかったしまた見返したい時に大変だったので記事の貼り付け＆メモ書きを残しとく

TimdaikTimdaik

歴史

特に歴史まとめが好きかも

JavaScript/エコシステム

https://zenn.dev/mizchi/articles/3789a101dae388d98159

https://d.potato4d.me/entry/20220405-nodejs/
Node.jsという実行環境によって、フロントエンドに限らずサーバーサイドやデスクトップ（今はどのくらい使われてるんだろ）、React Nativeによるモバイルと、広い範囲でJavaScriptが書ける。
これは分かりやすいところとしてJSという言語のノウハウを活かせる楽さがあって、それには各環境で広く使われているReactの存在が大きい。

https://zenn.dev/mizchi/articles/todays-javascript

「JavaScript の主戦場は AST パイプラインである」
その主張をする Node/フロントエンド陣営と、 そこにコストを掛けたくない片手間JS(ES5)水準で文化が大きく分離した。

そこからサーバーサイドではここを舞台とする様々な言語へとコンパイルできるAltJSが誕生していったが、JavaScriptのエコシステムに寄り添わない仕様・態度が仇となり、フロントエンドへの懸け橋になれなかった印象を感じた。

その結果ある意味温和なTypeScriptが生き残ったが、筆者はJSの曖昧な言語仕様に伴う緩い型システム（言語仕様が他の厳格な静的型付け言語に比べハッキリしていないことや、設定ファイルで型チェック含めたJSへのコンパイルの厳しさが変化してしまうなど）による安全性の担保が難しいことから、TypeScriptへの熟練度がプログラムの安全性に直結する。

ここでの設定ファイルで安全性が変化してしまうことの懸念は、自分らのプロジェクトというより使用するライブラリについてのことだろう。自分らの手の届く範囲では厳格な設定ファイルを敷けばそれでいいが、ライブラリはその範囲外であるため、使い始めてから後悔するリスクを少しでも減らすためにもそのライブラリを使用しても構わないかを判断する材料の1つになると感じた。

保守性の観点から、プログラムを動かすために守らないといけない規則や必要な思想をなるべく例外が無いように定めている言語が実務では必要だろうと感じていて、その面では厳しいコンパイラを持つ静的型付け言語であり関数型言語であるHaskellに興味を持って学んでいる（Rustも気になる）。
ただこれからもWebフロントエンドをやっていきたい身としてはJSおよびTSを使っていくことになるだろうから、TSの熟練度を上げていく方向性にはどうしてもなりそう。

SPA

https://zenn.dev/mizchi/articles/spa-engineers-history

TimdaikTimdaik

フロントエンドフレームワーク

https://zenn.dev/mizchi/articles/micro-frontend-qwik

Qwik は現代のフロントエンド最適化技術を全マシマシの二郎系みたいなフレームワークだ。 Svelte のコンパイル時最適化と、Astro のアイランドアーキテクチャをさらに推し進めて関数単位でハイドレーションすることを前提に API 体系が整理されている。 SSR を前提にすることでコンパイル時にほとんどを処理してしまい、SSR 時以外で不要なものをクライアントから取り除いて、その上でブラウザイベントに応じて必要なものだけ選択的にロードする。その結果発生する細かく区切られたチャンクは ServiceWorker で積極的に先読みする。

Qwikって名前しか知らなかったけど、2023年当時はReactを始め各フレームワークの最適化の思想をつぎ込んだが故に厳しい制約を備えた"理論上最強"みたいだ。
フレームワークにはこれまでのWeb技術の思想と意匠が詰まっているので、フレームワークを学ぶことで得られるものは多そうだ。

TimdaikTimdaik

React

設計パターン

https://zenn.dev/globis/articles/c16eaadf3d233b

2015 年頃から広まったこのパターンですが、2019 年に React Hooks のコアチームメンバーである Dan Abramov が自身のブログ記事で「現在は推奨していない」と更新したことで、使われる機会が減ってきました。
彼が指摘したのは、Hooks の登場により「関数コンポーネントでも状態管理やライフサイクル処理ができるようになったため、パフォーマンス最適化以外の理由で無理に分ける必要がなくなった」ということでした。

しかしHooksによるロジックとUI Componentとの結合がUIのみの検証や再利用のしにくさに繋がっているとして、再度Container/Presentationalを再考した取り組み。
結果、以下の4つの要素に切り出した構成となった。

  1. UI 層（.ui.tsx）：純粋な見た目とインタラクション
  2. Container 層（.container.tsx）：データ取得とロジック統合
  3. Composition：外部からのコンポーネント合成・注入
  4. Hooks（useXxx.ts）：再利用可能なビジネスロジック

TODO: 最近関数型言語に入門していることもあり、Reactに対する自分の考え方をもう少し整理できそうに感じている。そのため再度この設計を見て検証する。

https://speakerdeck.com/honey32/mazu-container-yorishi-meyo
「コンポーネントを細かく分ける」
意外と実践できていない人多いけど、意識しないといけないことやと感じてる。
ライブラリの実装をたま～に見てても「その単位で分割しちゃうの！？」ってくらい小さなコンポーネントを見かける（その時はコンポの責務・状態に目が言ってなかったけどその目線付きだと納得かな）。

https://levtech.jp/media/article/column/detail_711/
フォルダ構成の話。さっきのスライドを踏襲するなら「まずフラット構造より始めよ」


記事内の画像を引用

このようなフローで徐々にフォルダ構成をスケールしていけばよく、最初はコンポの分類に迷わないフラットな構成からスタートする。