created: 2021-04-25T06:10:37.000Z
react-admin では ナチュラルキーのテーブルはうまく扱えない
rails や django などのフレームワークと同様、idカラムがない(もしくはpkにナチュラルキーが設定されている)テーブルは react-admin ではうまく扱うことができない。
このissueでキッパリと扱えないと言われている。
We said several times in the past that we don't want to do that. It's a strong design decision, but it allows us to develop complex features with much better confidence.
FAQ の先頭でも同様の質問があり、回答されているのだがこのやり方は react-admin=v3.14.4 の時点では実際に動作しない。動作させるためには挙げられている差分以外にも色々実装する必要がある。
pkがid以外の場合に実装の必要があるもの
無理矢理頑張ることもできるが、かなりメンテナンスコストがかさんでしまうのでそもそも楽をするために react-admin を採用しているならオススメできる方法ではない。
- 取得されたレコード行のpkカラムを
idという名前に変える - リクエストする sort/filter パラメータに
idが含まれる場合テーブルのpk名に変換する - アプリで1つのDataProviderを共用しているため、resource名ごとに分岐して
dataProvider自身はシンプルだがあまり拡張性の高い構造になっていないので、現実的には pk が idという名前でないテーブル (複合PKなど) は react-admin では使えないと考えたほうがよさそう。
それでも管理したい場合
pkがidでないテーブルを扱う時は React-admin 組み込みでなく自前の実装の画面を作ることになる。自前の resource を追加する方法はこちらに案内されていた。
ただし、それも組み込みのサイドバー/メニューバーのコンポーネントを再実装するという方法しかないようであまり現実的ではなさそうだった。1テーブルだけpkがidでないテーブルがあるだけで、デフォルトの出来のいいメニューバーに匹敵する車輪の再発命をして、それをメンテし続け る必要があるのは割が合わなそうである。おとなしくAPIサーバ側の処理で吸収した方がよさそうである。
結論
React-admin は rails や django などと同様にオートインクリメントのサロゲートキーを使う想定で作られている。もしそうでないテーブルを管理する必要がある場合は、サーバ側でうまいこと処理を書いてあげる必要がある。テーブルを作るときも、pk は integer/autoincrement にして、ナチュラルキーのほうは unique 制約をつけるようにしておくのがよい。
