dtaniguchi.com

blog

React18 にするか、Vue3 にするか

d.taniguchi

2023年9月22日 19:14

Post / コメント

  • Vue3

ありがたいことに、2023年9月より再び Frontend のリードエンジニアとして新規開発プロジェクトに参画している。しかも、今回 Frontend の担当者は私1人だけだ。

CTO、BE、FE にそれぞれ一人、総勢3名の小さなチーム。開発予定のソフトウエアはまだ構想のみ、要件定義も、画面デザインも何もないところからスタートである。私の最初の課題は技術選定だ。

仕様を考慮すると SPA が最善という結論に至ったが、フレームワークを React 18 にするか Vue 3 にするかはすぐ選ぶことができなかった。 Web 業界では、 Vue が一世を風靡したかと思ったら、また React へ軸足を戻してしまった。理由はよくわかる。 Vue がとどまることを知らない素晴らしい進化を続けるからだ。 Vite を生み出し、あっという間に TypeScript に対応、さらにデフォルトの API まで変更したと思ったら、 Vue2 の 2023 年末 EOL まで決めてしまった。背筋の凍る早さだ。 Vue3 には破壊的変更がある。Vue2 からたやすく移行を行えない。

今回案件探しをしている中に、 Vue2 から Vue3 への移行プロジェクトがあった。 Vue3 に触ってみたいだけの気軽さで応募したところ、「移行経験ない人お断り!」とけんもほろろに断られてしまった。この切迫感、当然である。いつ自分たちで修正不能なクリティカルレベルの脆弱性が見つかるとも知れないプロダクトが本番環境で動いていると思うとゾッとする。いや、むしろもうすでに山のような・・・。

Vue2 の公式では、やや申し訳なさそうに Vue3 はどうしても破壊的変更が不可避だったこと、 Vue2 の EOL 、そして今後のリリースは、下位互換を大切にしたいとする思いが語られている。

https://v2.vuejs.org/lts/#Upgrade-to-Vue-3

信用できない。長期的な運用を考慮するとやはり Vue を選ぶのは怖い。 React を Vite で動かすのが現状最善と考え CTO に提案したら、是非 Vue を採用してほしいと頼まれてしまった。

かくして私は Vue3 開発を行うことになったのだった。React であれば新鮮さもないが、Vue3 だと新しいことだらけだ。TypeScriptへの対応ぶり、Composition API の書き心地など、今から楽しみなのである。

推し Code formatter

d.taniguchi

2023年9月15日 23:43

Post / コメント

  • ESLint
  • Tips

9月より新しい新規開発プロジェクトに参画するのだが、契約手続きの関係でスタートが1日からではなく19日からになった。開始までにまだ時間がある。私は少し先回りして、普段はあまり時間をかけられないプロジェクト基盤周辺部に、じっくり取り組みたい心持ちになった。

技術スタックの検討が済めば、その後は VSCode の .setting.json にはじまり、Dockerfile、GitHub Actions、README.md への細々とした記述など、初期プロジェクトの作成者には準備しなければならないファイルがたくさんある。 Linter や Code formatter の設定も、そういったもののうちの一つだ。

直近参加した開発プロジェクトのいくつかは、いずれも Code formatter に Prettier を使用していたが、よい印象がない。私はソースコードの改行箇所と改行数を強制されるのが好きではなかった。関数内と関数間の改行数は変えたいし、桁数で強制的に改行されるのも1行に意味を持たせたい時に邪魔になる。

カスタマイズしてみようと Package を install してみたが、ダメだと気づくのに時間はかからなかった。設定項目がたった24種類しかないのだ。勝手に Format されるが、その内容のほとんどは条件の有無を設定できない。いらん。こんなものを Project に入れる気にならなかったので削除していたら、 ESLint に Code formatter の機能があることを知った。しかも ESLint なら、すべての条件で有効・無効の設定できるという。

https://eslint.org/docs/latest/rules/

設定項目は非推奨になっていないものだけで200種類もある。これだ。これこそ私の探し求めていたものだ。折角である。200種類すべて試してみる。

.eslintrc.cjs
/**
 * ESLint 設定
 *
 * @see https://eslint.org/
 */

module.exports = {
  root: true,
  extends: [
    "eslint:recommended",
  ],
  parserOptions: {
    ecmaVersion: "latest"
  },

  /**
   * カスタムルール
   *
   * [eslint]
   * @see https://eslint.org/docs/latest/rules
   *
   * @see https://typescript-eslint.io/rules
   *
   */

  rules: {

    /*****************
     * 構文に関する設定
     *****************/


    /*
     * [warn]
     *   開発中は使ってもいいが、本番までに削除
     */

    // console の使用: 警告
    "no-console": "warn",
    // alert の使用: 警告
    "no-alert": "warn",
    // 同一依存先から複数行の import: 警告
    "no-duplicate-imports": "warn",
    // () を使用する演算の省略: 警告
    "no-constant-binary-expression": "warn",


    /*
     * [error]
     *   開発、本番いずれも使用しない
     */

    // eval の使用: エラー
    "no-eval": "error",
    // 型のチェックを厳密に行えない equal ( == or != ) の使用: エラー
    "eqeqeq": ["error", "smart"],
    // Camel case 以外の変数、関数命名: エラー
    "camelcase": "error",


    // Array<T> -> T[]: エラー
    "@typescript-eslint/array-type": "error",



    /*************************************
     * Code Format に関する設定 (auto fix)
     *************************************/

    /*
     * [warn] 自動修正されるので、すべて warn 指定
     */

    // セミコロン: 不要
    "semi": ["warn", "never"],
    // タブ: 使用不可
    "no-tabs": "warn",
    // タブ・スペースの混在: タブを使用禁止にしているので off
    "no-mixed-spaces-and-tabs": "off",
    // 行末の余計なスペース: 削除
    "no-trailing-spaces": "warn",
    // インデント: 2文字
    "indent": ["warn", 2, { "SwitchCase": 1 }],
    // 改行コード: LF
    "linebreak-style": ["warn", "unix"],


    // 1行の文字数: 制限なし
    // https://eslint.org/docs/latest/rules/max-len
    "max-len": "off",


    // 空白行: 7行まで
    "no-multiple-empty-lines": ["warn", { "max": 7, "maxEOF": 0 }],
    // 最終空白行: 必須
    "eol-last": "warn",

    // 文字列リテラル: Double Quotation
    "quotes": "warn",

    // コンマの後のスペース: 必須
    "comma-spacing": "warn",
    // 最後の要素に付与するコンマ: 複数行の場合のみ
    "comma-dangle": ["warn", "only-multiline"],
    // コンマの位置: 後ろにのみ付与
    "comma-style": ["warn", "last"],

    // [] にスペース: 削除
    "array-bracket-spacing": ["warn", "never"],
    // {} にスペース: 必須
    "block-spacing": ["warn", "always"],
    // Object の key 定義 コロン前後のスペース: 後ろのみ
    "key-spacing": "warn",
    // オブジェクトのプロパティ obj[name] 空白: 削除
    "computed-property-spacing": "warn",

    // ブロック改行
    "brace-style": "warn",
    // 不要な括弧: 削除
    "no-extra-parens": "warn",
    // 不要なスペース: 削除
    "no-multi-spaces": "warn",
    // ブロック前後の空白: 必須
    "keyword-spacing": "warn",

    // 関数定義の関数名と引数の間のスペース: 削除
    "space-before-function-paren": ["warn", {
      "anonymous": "always",
      "named": "never",
      "asyncArrow": "always"
    }],
    // 関数定義の改行: 一貫性を強制
    "function-call-argument-newline": ["warn", "consistent"],
    // arrow 演算子 => の前後にスペース: 必須
    "arrow-spacing": "warn",


    // 初期値が設定された変数、定数に対する型宣言: 削除
    "@typescript-eslint/no-inferrable-types": "warn",

  },
}

かくして私の担当する新しい Project に相応しい、私の好みがつまった Code formatter が誕生したのだった。

ブログ移行

d.taniguchi

2023年8月28日 10:05

Post / コメント

  • blog
  • PHP
  • WordPress

以前、私は今とは違うURLでブログを書いていたのだが、そのとき使用していた Domain 『 .tech 』 は更新料がアホほど高いので、安くておなじみの 『 .com 』 を取り直して移行した。

『 .com 』は年間1,000円だが、『 .tech 』は5,000円もする。

『 .tech 』で公開していたブログは、完璧な Backup 体制を敷いていたので、コマンド一つでもれなく Backup がとれるし、docker-compose を叩けば本番と同じものが Local に立ち上がる。Domain どころか Web Server を変更したところで、移行は一瞬で完了していたところだったのだが、やめた。

今回は WordPress のカスタムテーマ開発とデザイン制作に取り組むことにしたのだ。前回は既存テーマから気に入ったものをひとつ選び、css ひとつ書かず使用していたのだが、結局なんの愛着も持てなかった。今回は自分で一からデザインし、カスタムテーマを自作したので気に入ったものにできた。久しぶりに書く PHP は楽しかった。

以前のブログではひとつの記事にじっくり取り組むことにしていたので、文章は長くなり更新頻度はすぐに下がってしまった。移行をきっかけにブログ内容や分量をすべて見直した。簡素な中身にすれば負荷なく日々の出来事を残せるだろう。