2025年5-6月の学習記録

CMSの「Kuroco」

Kuroco + Node.js の基本的な環境構築ができるようになった。
といっても、会員システムクイックガイドを手順通り実行しただけですが。

GitHub Actions

これまでは CI/CD に「circleCI」を使う案件に多く携わってきたが、最近は「GitHub Actions」を使う案件にも携わるようになってきた。

フロントエンドエンジニアの私が直接 CI/CD 設定を書くことはないが、基本的な画面の見方は分かるようになった。
例えば、デプロイのジョブがスキップされていたら「何かおかしいなー BE に報告しておくか」と判断できるようになったり。
あとは「Artifacts」から、ビルドを経て実際に出力されたファイルを確認したり。など。

モーダル

いつもお世話になっている「TAKLOG」さん。

下記を参考にモーダルを実装したら、まぁ楽ちんでびっくりしました。

「モーダルの制御が大変で何日もかかる...」という FE の嘆きは、近い将来、消えてなくなるかもしれませんね。

cakePHP で最適な「入力フォームがエラーの時のCSS設定」

例えば、入力が必須のフォーム（required）でエラーが起きたとき、枠線の色をピンクに変更したいとします。擬似クラス :invalid を使えばよいでしょうか？

正解は❌です。擬似クラス :invalid を使うと、そのページを開いた瞬間に required の判定が行われるため、ユーザーがまだフォームに触れてもいないのに枠線がピンク色になってしまい、過剰な案内となります。代わりに、擬似クラス :user-invalid を使えば、ユーザーが一度操作した後でエラーが起きている場合のみ、CSSを変更することができます。

しかし、これで事態は解決ではありません。
例えば「フォームに入力する → 保存ボタンを押す → エラーがあるとき同じページを再表示してアラートを表示する」という実装の場合を考えてみましょう。
エラーがあって同じページを再表示する場合、最初から枠線をピンク色に強調しておくほうが分かりやすいですよね。しかし、:user-invalid の設定では、ユーザーが一度フォームを操作するまでは表示が変わりません。

したがって、あるページの 「1回目の表示」と「2回目以降の再表示」で、設定を分ける必要があります。

ここまでは CSS の一般論です。
以下は、cakePHP を使っている場合の話です。

cakePHP の標準ヘルパーで実装している場合、「2回目以降の再表示」では <input> を囲んでいる <div class="input"> に error というクラスが付くはずです。このクラスを使って、「1回目の表示」と「2回目以降の再表示」の CSS 設定を分岐させればよいのです。

style.scss

input[type="text"],
input[type="email"],
input[type="number"],
input[type="tel"],
input[type="password"],
select,
textarea {
    /* 初回のページ表示 → user-invalid */
    /* required のフォームが空でも、ユーザーが操作するまではエラーとして強調しない。 */
    :not(.input.error) & {
        &:user-invalid:not(:focus) {
            border: 1px solid pink;
        }
    }

    /* 2回目以降のページ表示（例：保存ボタンを押すもフォームにエラーがあり、同じページを再表示した場合） → invalid */
    /* ページを開いた瞬間に、required の空判定・強調表示を行う。 */
    .input.error & {
        &:invalid:not(:focus) {
            border: 1px solid pink;
        }
    }
  }

※なお、上記コードは「SCSS」でも「CSS」でも動きます。

ファビコンの設置

ファビコンの設置は曲者です。

上記の記事によると、必要なファビコンは３種類だけだそうです。

しかし実際には iOS safari での挙動は少々気難しく、もっと多くの種類のファビコンを用意する必要がありそうです。
たとえば、safari の「リーディングリストのタブ」ではファビコンが表示されるけど、「履歴タブ」ではファビコンが表示されないといった現象が発生します。

一体どこまで必要で、どこまで不要なのか。その見極めは今後の課題です。

モック作成で考えるべきこと

Figma などのデザインデータを見て HTML モックを作るときに、見落としがちなことがいくつかある。以下に列挙する。

• <form> で囲う範囲はどこからどこまでか？
• これは <button> か？<a> か？
  • デザイン上、ボタンのような見た目であっても <button> で実装されるとは限らない。例えば基本的な CRUD（データ/ページの作成・読み込み・更新・削除）を操作する "ボタン" の場合、<a href="/hogehoge/edit/1"> というように <a> で実装されることが多い（cakePHPの場合）。しかし、操作の前後に特殊な処理を噛ませる場合は <button> で実装されることも多く、特に「削除」ボタンなんぞは <a href="/hogehoge/delete/1"> であったり <button> であったり千変万化である。
  • FE がデザインデータだけを見て <button> か <a> か判定することは困難なため、BE に質問するのが無難だろう。また、<button> の場合と <a> の場合の両方のパーツをモックに用意しておく、という手もあると思う。
• 入力必須のフォームに required をつけるか？つけないか？
  • つまり、ブラウザ標準のアラートを使うのか。それとも独自実装のアラートを使うのか。デザインデータで表現されていないことが多いため、デザイナーやPMなどに確認する必要がある。
• ページネーションのDOM構造は、cakePHP のデフォルトパターンに合わせる。

最後に余談

Redmine と Qiita は「マークアップ記法」が異なる。なかなか書き方に慣れず、ストレスが溜まる。

• Redmine → 独自のRedmine記法（≒ Textile記法）
• Qiita → Markdown

メモアプリ「Notion」を数年使っている。これが Markdown 記法であることに最近気がついた。早く Markdown に慣れたい。

趣味で MediaWiki の編集も行っている。余計にこんがらがる。早く慣れたい。