僕自身のJS関連技術に関しての考察をここでつらつらとまとめたりアップデートしていったりしていきたい

言語関連

ECMAScriptの最新版を使うのは完全にありだと思う。ここに技術的難易度はあまりなく、メンバーへのフォローもしやすい。stage-x の技術とかもそれなりに問題なく使える。むしろここを変に以前のバージョンに固定すると、メンバーのアンガーがたまりすぎるので気をつけよう。

TypeScript

TypeScriptは絶対に導入すべきだけど、静的型付け言語を未経験の人には少しつらいかもしれない。ここのフォローをどうやっていくかは課題。なにかこの層の人たち向けの TypeScrpit 教材を渇望する。型に関する営みにピンと来ない人が多いので、型があると何が嬉しいかを最初に教え込むことが大切そう。また、この層の人たちにはVSCodeの導入と、プラグインなどの設定をオンボーディングすることが絶対に必須。

Linter, formatter

ひとまず eslint, prettier は絶対必須。

ただしどこまで Lint 設定を強くするかは、チームの性質による。TypeScript で躓くタイプの人が多いチーム、もしくはバックグラウンドが違いすぎる人が多いチームなら、ある程度強めの設定にして、かつ粘り強いフォローが必要になる。

Git pre-commit Hook

少数精鋭かつ、合意形成がうまくいってるチーム、個人なら不要。多人数チームなら必須。

React

2021年時点では特別な理由がなければ Next.js で良い。どうしてもNext.js にマッチしない要件がある場合、素の Reactを使う。もちろん React Hooks を使う。

自走できる人には公式ドキュメントを一通り読んでもらう。ただ、旧来のフロントエンド系の人だと Hooks でつまづきやすい。特に useMemo, useCallback がなぜ必要なのかと、第2引数についてピンと来ない傾向があるようなので、フォローが必要。

また、Next.js 特有のクセは、デキる人相手でもNext.js達人以外にはフォローをしてあげることが必須。

ステート管理

正直、現状だとコレというものはないため、ローカルステート以外は、カスタムフックを作ってアクセスする設計が必須。Contextを使うにせよ、他の何かしらを使うにせよ。設計センスが必須となるため、純粋培養なフロントエンドエンジニアには厳しいかもしれない。

でも、そもそも、テスタビリティとか設計論的に、そういう設計をサボんなよって話でしかない。すみません。

Recoil

個人的には Recoil はすごくありな気がしてる。が、それでもカスタムフック関数で抽象化するレイヤー設計をサボって良い理由にはならないと思っている。

react-query, SWR

マッチする場所で使うためのもの。とりあえず Next.js 使ってるなら必要な場所で SWR 使うでいいとは思う。

Redux

使いたくない。

CSS

CSSはガイドラインは早めに作るべき。

CSSライブラリ

個人的にはもう tailwindcss でいいじゃんになってる。少なくとも CSS in JS のくっそ面倒くささと性能劣化との戦いにはうんざりしている。

ただし、tailwindcss は config.js を作り込む or 追加することが必須なため、そこで転ばないようにはする必要あり。追加したつもりがオーバーライドしちゃったとか。

また、場合によってはカスタムフックとか、モジュール化が必要かもしれない。設計次第。

デザインシステム

TBD

デザイナーとどう連携するか

TBD

Node.js

JSエコシステムにおいて、Node.jsを使わず開発はできないので、Node.js に関する知見は絶対に必須。

バージョンをどうするか

基本的には最新のLTSを使うこと。ライブラリのアップデートをサボると最新への追従が困難になりがちなので、破壊的変更のあるライブラリを選択した場合、ライブラリ自体のアップデートは計画的に行なわなければならない。

M1 Mac では一時期は v15.6.0 でしか動かないとか色々あった気がするけど、いまだと anyenv + nodenv とかで普通にはいる LTS でも current でも動く（ただし、変なところで落ちるときはまだ残ってるので転んで泣かないように注意。2021/3/6現在）

Node.js本体のバージョン管理

またそれに伴った Node.js バージョン管理の仕組みを導入すべきだけど、これは見事に OS によって最適解が全く異なることに注意しなければならない。たとえば Windows だと以前は Nodist が良かったが現状ではもうメンテナンスされてないなど。あとanyenv + nodenv が今だといいかもしれないけど、導入手順が面倒だったり nodenv も将来どうなるかはわからない。

ここらへんはオンボーディング重要。手順を手厚く残す、セットアップを手伝うなどが必要。

パッケージ管理

npm or yarn は正直好みでいいと思う。僕は yarn が好きだけど、最近の npm は以前よりはめちゃくちゃマシになってる。ちなみにnpm v7 以後は package-lock.json が v1 から v2 になってるので、プロジェクトで採用するなら npm 自体のアップデートをメンバー全員にさせる必要あり。

バックエンドJS

Next.js の場合、SSRとかしなくてもある程度バックエンドJSの知識が必要になる。たとえば、ある場所にあるファイルを import ではなく、ファイルとして読み込みたい場合は変に Webpack職人になるくらいならgetStaticPropsとか使ったほうが絶対に楽。

React Server Components

まぁまだアイデア段階ではあるけど、登場時には React Hooks 並にパラダイムシフトすると思ってる。今の PoC ではアップデートが課題だけど、そこはいい感じに解決するじゃろうきっと。

ここらへんも鍵は Next.js が握ってるとは思っていて、今後に期待。

自動テスティング

基本となるテストランナーは jest 一択。あと @testing-library/* を採用してれば大体間違いない。

Cypress

扱いがめんどいところはあるけど便利なのは間違いない。問題は記述するのが面倒とか、テスト時間が問題になるが、そこはコストが支払えるなら採用する、でいいと思う。

レイヤー設計

もう設計論不要のなんでもありの、無垢な時代は終焉を告げた。

コンポーネントインターフェース設計

material-ui とか既存のものを使わない場合、既存のモノになるべく似せておくと良さげ。あとコンポーネントには絶対に JSDoc 形式のかんたんな説明文を書くこと。

Atomic Design

ある程度ありだとは思うけど、大体持て余す。そもそもにして、コイツはデザイン設計論でかつ、無理のあるもの（そもそもなんで原子だの分子だのって、余分な単語が必要やねんという意見がある）。

Atomic Design そのものはフロントエンド開発にマッチしづらいが、指針としては悪くない部分もあるので、噛み砕いて、設計論としてうまく考えていくべきだとは思う。

see. Atomic Designから派生した、“オルタネイティヴ”な5つのデザインシステム - ログミーTech

ただまぁ、これらのどれが適切かなんて誰もわからないので、自分たちにあったやり方をカスタムする以外の選択肢が現状ではない。

モジュール

ここではコンポーネントを Reactのコンポーネント（つまりビューを司るもの）として、それ以外のものを雑多にモジュールと呼ぶ。

モジュールをどう扱うかは悩ましい。特に設計論に疎い、純粋培養フロントエンドエンジニアはポカーンとしがち。

src/hooks みたいなディレクトリを作るのはナンセンスだ。hooks などというレイヤーは存在すべきではない。カスタムフック関数は、ただの仕組みであり、それ自体はレイヤーにはならない。まだ、レイヤーを作るためのベースであると認識するほうが話としては近い。

モジュールは必ずユニットテストが存在すべきで、もしユニットテストを書きづらい実コードがあったら、それは、そのコードの設計が不適切なので、SOLID原則など、開発の基礎に立ち戻る必要がある。

TBD

VSCode

フロントエンド系の人なら、基本的には特別な事情がなければ VSCode 一択であるべき。

すでに JetBrains 製品を使いこなしてる人たちは WebStorm などを使うのはあり。ただし LiveShare のためだけに、並行でインストールはしてもらいたい。

VSCode 番長

VSCodeの設定は割とバージョンアップで変わるし、拡張周りもあれこれあったりするので、ある一定以上の人員がいるなら、VSCode を常に検証し続けるような VSCode 番長がいるべき。

これは JetBrains の IDE でも同じことが言えると思う。

導入すべき拡張

TBD

入れるべき設定

TBD