hatake

表示

行ごとの操作を付ける ​

編集・削除など、一覧の各行に出すボタン。

一覧の各行に出すボタンは table.rowActions にアクション id の文字列を並べる。

yaml
table:
  rowActions: [edit, delete]
  columns:
    - { field: code, label: コード }
    - { field: name, label: 顧客名 }

edit と delete は宣言しなくていい ​

この2つは組み込みなので、rowActions に名前を書くだけで動く。actions に定義を足す必要はない。delete は確認ダイアログも自動で出る。

宣言を足すのは、その確認の文を業務の言葉にしたいとき（と、終わったあとに何かしたいとき）。

yaml
table:
  rowActions: [edit, delete]

actions:
  - id: delete
    type: delete
    confirm: { message: この顧客を削除すると受注履歴から辿れなくなります。よろしいですか？, danger: true }
    onSuccess: { message: 顧客を削除しました }

この宣言が読まれるのは id: delete（組み込みと同じ名前）で、rowActions に delete が並んでいるとき。宣言は画面上部のボタンにはならない（行の操作なので、並べても押しても何も起きないボタンになる）。どこにも効かない書き方は validate が言う（row-declaration-unused）。

編集の側（type: edit）には confirm を書いても読まれない。行の編集は入力の枠を開くだけで、そこでは聞かないため。

独自の操作を出すときは actions に宣言する ​

組み込み以外を並べるときは、同じ id のアクションを actions に定義しておく。宣言していない id を書くと、ボタンが出ないか何も起きない（validate が警告する）。

yaml
table:
  rowActions: [detail]
  columns: [...]

actions:
  - { id: detail, type: plugin, plugin: showDetail, label: 詳細 }

行ごとに押せるかどうかを変えるなら enabledWhen。行アクションはその行のレコードで判定するので、「出荷済の行だけ灰色」が定義で書ける（→ アクション）。

行から別の画面へ飛ばすなら navigate にして、params で行の値を渡す。

yaml
actions:
  - { id: openDetail, type: navigate, label: 詳細, page: order_detail,
      params: { orderNo: "$row.orderNo" } }

どの画面でも同じ所に出る ​

行のボタンは行の右端に、並べた順に出る。search でも crud でも master でも同じで、書き方も同じ（rowActions に id を並べるだけ）。crud / master では組み込みの edit / delete も同じ列に混ざる。

yaml
table:
  rowActions: [detail, edit, delete]   # この順に出る

押した行はハンドラに渡る（ctx.record）。navigate なら params に $row.<項目名> で行の値を差し込める。

一括のボタンは行に並べられない ​

scope: selection のボタン（→ 一括のボタン）を rowActions に並べても、行には出ない。

行のボタンは「押した行」に実行するもので、一括のボタンは「チェックした行」に実行するもの。行に並べると、押した行ではなくチェックした行に実行することになる ── 何もチェックしていなければ押しても何も起きない。一番静かな壊れ方なので、行には出さず一覧の上の一括ボタンとして出す（行から消してしまうと、どこからも押せないボタンになる）。

並べても壊れないが、効いていないので npx -p @hatake-fw/api hatake validate が言う（selection-as-rowaction）。読み返し（npx -p @hatake-fw/api hatake explain）も「行には出ない：選んだ行に実行するボタン」と書く。

画面上部のボタンとの使い分け ​

同じ actions に書いたものが、rowActions に載せれば行のボタン、載せなければ画面上部のボタンになる。判断は「1件に対する操作か、画面全体に対する操作か」で切る。

操作置き場所
この行を編集する・削除する・詳細を見るrowActions
新規登録する・CSV を出す・検索結果全体を処理する画面上部（actions だけ）

読み取り専用の画面でも使える ​

search（照会）にも rowActions は書ける。ただし edit / delete は書かない — 照会画面は更新しないという前提の種別なので、変更する操作を置くなら種別が crud か master のはず。照会画面に置くのは detail や CSV 出力のような、データを変えない操作にする。

書いても行には何も出ない（黙って消える）ので、そこは validate が言う（builtin-rowaction-unsupported）。

書けるキー ​

キー書く場所型必須既定値有効なページ種別説明
rowActionstablearray of string （edit / delete ほか）任意—crud master report searchPer-row action ids. Built-ins: edit, delete.

この表は spec/reference.json から生成している（JSON Schema が正）。手元では npx -p @hatake-fw/api hatake reference <キー名> で同じものが引ける。

近い例 ​

例は丸ごと写して直すのが一番速い。以下は CI で検証済み（そのまま動く形）。

ファイル種別画面どういうときに使うか
customer_master.yamlcrud顧客マスタ検索して一覧に出して、その場で登録・修正・削除まで面倒を見る画面が欲しい
dept_master.yamlmaster部門マスタコードと名前だけの小さなマスタを、最小の定義でメンテしたい
product_search.yamlsearch商品照会検索して一覧を見るだけ（登録も更新もさせない）画面が欲しい
order_lines.yamlapp受注明細受注番号だけでは1件に決まらない表を出したい（明細・履歴・年度別の実績）

よくある間違い ​

rowActions にオブジェクトを並べる ​

なぜ駄目か rowActions はアクション id の文字列配列。中身（ラベル・型）は actions に1回書く。edit / delete は組み込みなので宣言も要らない。

こう直す rowActions: [edit, delete] のように書く。独自の行アクションは actions に { id, type, label } を足して、その id を並べる。

yaml
page:
  type: crud
  id: customer_master
  title: 顧客マスタ
  repository: customerRepository
  table:
    rowActions: [edit, delete, openDetail]
    columns:
      - { field: code, label: コード }
  actions:
    - { id: openDetail, type: navigate, label: 詳細, page: customer_detail,
        params: { id: "$row.id" } }

spec/pitfalls.json から生成。各項目は CI で検証済み（間違いは本当に落ち、正しい方は本当に通る）。手元では npx -p @hatake-fw/api hatake pitfalls <キー名>。

実物を見る ​

デモアプリの「顧客マスタ」がこれを使っている。 デモを開く