rails勉強メモ4 – serializerとかroutingの話とか –

activeModelSelializerの話

serializerを使ってる場合はrender json: でrootのkeyを指定できる

また、普通にjsonを返したい場合は以下のようにしてもダメ

レコードの存在確認

レコードがあるかどうかは以下のメソッドで可能

ActiveRecordSerializerを使用してjsonを返したい場合はserializerの中にメソッドを作って返すようにするとよい

routingのmoduleとnamespaceとscopeの話

単純にroutingのどの部分に関係してくるかという話

urlもcontrollerのフォルダ構成も同じようにネストしてる場合

例えば/users/1/likesで users/likes#index routingがあるとする。
特徴としては、url上でもusersの下にlikesが存在しているところ。

このようにどちらも同じような構造になっている場合はnamespaceを使うと一発で出来る

こうすると以下のようにurlもcontrollerもネストした感じになる

urlはネストしてるけどcontrollerが入っているフォルダはネストしてない場合

例えばurlは先ほどと同じで/users/1/likesでcontrollerはフォルダの外にある場合 likes#indexは、scopeを使いましょう。

そうすると以下のようになります。
urlだけネストされてますね!

urlはネストしないけど、controllerのフォルダ構成はネストしてる場合

今度はurlはネストしてないけど、controllerはネストしている場合です。
例えば、 /likesusers/likes#indexを参照するなどですね!(こんな場合マジでないと思うけど)。

この場合はmoduleを使います。

すると以下のように、urlはネストしてないけどcontrollerはネストするようになりますね!

RoutingとControllerとmodleの話

なんか1つテーブル作ろーとか思ったときに、model作ってーcontroller作ってーrouting作るみたいなことをやる。
こいつらのフォルダ構成とかはどのように考えるべきか。

まず、routingとcontrollerの組み合わせとmodelを分ける。
ここはもうはっきり分ける。

極端な話、controllerはroutingと同じようなディレクトリ構成、url構成にしちゃう。
そうするといわゆるRailsの 設定より規約を重視する(Convention over Configuration、CoC)の恩恵を受けることが出来ます。

またmodelはcontrollerなどとは全く別物です。
medelは開発者がどう処理したいかを実現する場所です。
なのでバックエンドのロジックにおいての構成になります。

migrationファイルのリファレンスの話

migrationファイルを書くときに外部キーなどを明示的に書くことが出来る
例えば、UserモデルがLikeを複数持っている(has_manyとbelongs_toの関係性)場合、いかのようにreferencesを使用することで外部キーだよって書くことが出来る。
後から見返したらわかりやすい!
なんかこれでmigrateしたらmodelにbelongs_toとか記述されるって聞いた(けど確かめてない)

ちなみにDBレベルで外部キー制約するときはforeign_key: trueをつけるとよい

スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク