Vueでパスワードの強度を動的に判定できる送信フォームを作りました。

タイトルの通り、Vueでパスワードの強度をクライアントサイドで判定しながら送信できるフォームを作りました。

PasswordStorengthChecker

JSFiddle上に置いておいたので、欲しい方はどうぞ。編集自由ですが、ブログ等での再配布はご遠慮ください。

jsfiddle.net

挙動については本当にgifで見てもらった通りなのですが、４つの条件（文字数、小文字、数字、大文字）を満たしたパスワードのみ送信を行うというものです。

多すぎる条件はユーザー体験を損ないかねないので、４つも条件が必要かは微妙なところですが、セキュリティに関するところというところもあり、判定が甘すぎるよりはいいと思います。

以下、コードの解説です。Vueに興味のない人は最後の余談だけでもよければ御覧ください。(大したことは話してません)

HTML側

<div id="app">
  <div class="container">

    <div class="input_container">
      <label for="name" class="label">パスワード</label>
      <input type="password" @input="onCheckedBeValid" v-model="password" placeholder="6文字以上" />
      <span v-bind:class="{ valid_password_length: validPasswordLength }" class="password_length">{{passwordLength}}</span>
    </div>
    
    <div class="validation_container">
      <p v-bind:class="{ lowercase_valid: containsLowercase }">小文字</p>
      <p v-bind:class="{ number_valid: containsNumber }">数字</p>
      <p v-bind:class="{ uppercase_valid: containsUppercase }">大文字</p>
    </div>

    <div class="button_container">
      <button @click="signUp">登録</button>
      <p>{{ message }}</p>
    </div>

  </div>
</div>

inputタグについて

<input type="password" @input="onCheckedBeValid" v-model="password" placeholder="6文字以上" />

@inputで「inputイベント」が起こるたびに着火されるメソッドを指定し、入力された値(value)については、v-model="password"を使って、双方向バインディングしています。

spanタグについて

<span v-bind:class="{ valid_password_length: validPasswordLength }" class="password_length">{{passwordLength}}</span>

属性の値を動的にセットできるv-bindを使い、今回はclass属性の値を動的にセットしています。

「v-bind:class="{ valid_password_length: validPasswordLength }"」というのは、validPasswordLengthがtrueのとき、valid_password_lengthというクラスをこのタグにセットするという意味になります。これを使い、文字数が条件を満たしたときだけに、動的にクラス名をセットして、付与されるスタイルを変更しています。

JS(Vue)側

new Vue({
  el: "#app",
  data () {
    return {
      password: '',
      message: '',
      passwordLength: 0,
      containsLowercase: false,
      containsNumber: false,
      containsUppercase: false,
      validPasswordLength: false,
      isValidPassword: false
    }
  },
  methods: {
    onCheckedBeValid () {
      this.passwordLength = this.password.length

      this.passwordLength > 5 ? this.validPasswordLength = true : this.validPasswordLength = false
      this.containsLowercase = /[a-z]/.test(this.password)
      this.containsNumber = /\d/.test(this.password)
      this.containsUppercase = /[A-Z]/.test(this.password)
    },
    checkAllValidations () {
      if (this.containsLowercase 
          && this.containsNumber 
          && this.containsUppercase
          && this.validPasswordLength) {
        this.isValidPassword = true 
      } else {
        this.isValidPassword = false
      }
    },
    signUp () {
      this.checkAllValidations()
      this.isValidPassword ? this.message = '送信しました' : this.message = 'パスワードに問題があります'
    }
  }
})

メソッドの簡単な説明を残しておきます。

onCheckedBeValidメソッド

Inputイベントで着火するメソッドで、入力されたパスワードが先に述べた4つの条件を満たすかどうかそれぞれ判定します。ここでtrueになった条件たちは、HTML側で:classにバインドされているので、それぞれスタイル付与に貢献します。

checkAllValidationsメソッド

メソッド名通り、全てのバリデーションをチェックします。

signUpメソッド

ここにバックエンドにアクセスするための非同期通信の処理を書きます。axios等を使いましょう。ここでは記述を割愛しています。

CSS側

.container {
  margin: 30px auto;
  height: auto;
}

.input_container, .validation_container, .button_container {
  display: block;
  margin: 0 auto;
  height: auto;
  display: flex;
  justify-content: center;
}

.password_length {
  padding: 2px 10px;
  margin-left: 120px; 
  background: rgb(236, 57, 57);
  color: white;
  border-radius: 10px;
  font-size: 13px;
  transition: all .1s;
  position: absolute;
}

.valid_password_length {
  background: green;
}

.validation_container p {
  width: 80px;
  margin: 5px;
  height: auto;
  font-size: 12px;
  text-align: center;
  border-radius: 2px;
  color: rgba(71, 87, 98, .8);
  background: linear-gradient(to right, green 50%, #eee 50%);
  background-color: #eee;
  background-size: 200% 100%;
  background-position: right;
  transition: background .3s;
}

.lowercase_valid,
.number_valid,
.uppercase_valid {
  background-position: left !important;
  color: white !important;
}

p {
  margin: 0;
}

一番のポイントは緑色のバーが動的に動くところだと思うので、そこの部分だけ抜粋します。

 .validation_container p {
  background: linear-gradient(to right, green 50%, #eee 50%);
  background-color: #eee;
  background-size: 200% 100%;
  background-position: right;
  transition: background .3s;
}

.lowercase_valid,
.number_valid,
.uppercase_valid {
  background-position: left !important;
  color: white !important;
}

こちらがその部分です。文章だけで解説しますが、まず、2行目のbackground: linear-gradient(to right, green 50%, #eee 50%);で「左50%が緑、右側50%が白色の背景」をセットしています。そして、background-position: right;で、「その背景の右側（白色）を自分のポジション」として固定します。

次に、「パスワードが条件を満たしたときのクラスの追加」で、background-position: left !important;というスタイルを付与することで、今まで右側（白色）にいた自分が、左側（緑色）に移ります。その移動をトランジション要素で動的に行うことで、白色と緑色の境界線が、まるでバーの動きのように表現されているというわけです。

コンポーネント・モジュール化

新規登録画面が２ページ以上ある場合は、このフォームをコンポーネント化しておいた方がいいと思われますが、２ページ以上あるサイトはあまりないと思われますので、必要になるまでは共通化しなくてもいい気がします。自分は共通化せずにそのまま使ってます。

「条件を満たすと満タンになるバー」は、他の部分で再利用できそうなので、そこはコンポーネントにしてもいいかもしれまん。

余談

４つの条件をわざわざ満たさせるフォームはユーザにとって煩わしさはあるかもしれませんが、認証情報はサイトの核なので、特に「決済システム」などの重大な機能をもつサイトを運用する場合は、このようなフォームでパスワード強度を動的に確認してあげるとよいと思います。

バックエンドに渡す前にバリデーションにかけれるので、無駄な通信も防げてエコですしね。（だいぶ微々たるものでしょうけど）

おしまい。

Vueで画像アップロード + プレビュー機能付きフォームを作りました。(Base64エンコード利用)

タイトルの通り、Vueで簡単な画像アップロードページを作ったので、JSFiddleで公開してみます。

今回はBase64エンコードを使って、画像を文字列情報として扱う方法を採用しています。

バックエンドとのやり取りをJSONベースで行っている場合は、この方法がシンプルで扱いやすいと思います。

VueImageForm - JSFiddle - Code Playground

挙動については上のリンクに飛んで触っていただければすぐにわかると思います。簡易的な画像アップロード機能と、画像送信前のプレビュー機能のついたフォームです。

ほしい方は勝手に使っていただいて大丈夫です。編集も自由です。変な所あったら勝手に直しちゃって下さい。（そしてこっそり教えて下さい。）

「なんでBase64エンコード使ったん？」という件については、一番最後の余談で書いたので、Vue興味ない方はそこまで飛ばして下さい！！

一応、それぞれのコードの解説を書いておきます。

HTML側

<div id="app">
  <p id="error" v-show="error">{{ error }}</p>
  <label>
    <p>クリックで画像を変更できます。</p>
    <img :src="avatar" alt="Avatar" class="image">
    <div>
    <input
           type="file"
           id="avatar_name"
           accept="image/jpeg, image/png"
           @change="onImageChange"
           />
    </div>
  </label>
  <button @click="upload()">アップロード</button>
  <p>{{ message }}</p>
</div>

labelタグについて

これでimgタグとinputタグを囲めば、inputタグのクリック可能範囲を広げ、画像クリックに判定が付きます。

imgタグについて

:src="avatar"で、Vue側がもつdataの「avatar」をバインドしてきています。Vue側のavatarの値が変更されれば、src属性の値は自動で更新されます。

avatarのデータ型はStringで、画像をBase64でエンコードしたものを渡しています。Base64形式でsrc属性に値を渡せば、特別な処理を書かずとも画像を表示できます。

Base64エンコードとは？

データを文字列として表す変換方式です。メールの添付等でよく使われるようです。

inputタグについて

@change="onImageChange"は、inputでファイルが変更されるたびに、onImageChangeメソッドが実行されるという意味です。

ここは「v-model="avatar"」でも動きそうに見えますが、inputのtype="file"はvalueをもつことが出来ないので、v-modelでavatarをセットしても、その値をinputタグが保持しておくことができずにエラーが出ます。

JavaScript(Vue)側

new Vue({
  el: "#app",
  name: 'ImageUploder',
  data () {
    return {
      avatar: '',
      message: '',
      error: ''
    }
  },
  methods: {
    setError (error, text) {
      this.error = (error.response && error.response.data && error.response.data.error) || text
    },
    getBase64 (file) {
      return new Promise((resolve, reject) => {
        const reader = new FileReader()
        reader.readAsDataURL(file)
        reader.onload = () => resolve(reader.result)
        reader.onerror = error => reject(error)
      })
    },
    onImageChange (e) {
      const images = e.target.files || e.dataTransfer.files
      this.getBase64(images[0])
        .then(image => this.avatar = image)
        .catch(error => this.setError(error, '画像のアップロードに失敗しました。'))
    },
    upload () {
        if (this.avatar) {
        /* postで画像を送る処理をここに書く */
        this.message = 'アップロードしました' 
        this.error = ''
      } else {
        this.error = '画像がありません'
      }
    }
  }
})

各メソッドについて、簡単に解説します。

getBase64メソッドについて

getBase64 (file) {
  /* Promiseにアロー関数を渡して非同期処理を書く。*/
  return new Promise((resolve, reject) => {
    
    /* 組み込みオブジェクトを使い、Base64エンコードされた画像データを取得  */
    const reader = new FileReader()
    reader.readAsDataURL(file)

    /* 成功時と失敗時の処理。resolveの引数に結果を渡して、のちの.then(result => ...)で受け取る  */
    reader.onload = () => resolve(reader.result)
    reader.onerror = error => reject(error)
  })
}

onImageChangeメソッドについて

inputでファイルが入力されると着火されるメソッドです。イベントオブジェクトからファイルを貰い、そのもらったファイルをBase64エンコードしたものを、avatarにセットしています。これでavatarの値が変更されるのですが、そのとき、その変更を検出したimgタグがsrc属性に新たなavatarの値を当てはめます。すると、選択したファイルの画像が表示されます。これがプレビュー機能に当たる部分です。

uploadメソッド

バックエンドにBase64エンコードされた画像を送る処理を書くところです。今回は詳しい処理については割愛していますが、axiosでバックエンド側のAPIにpostまたはpatchする処理を書きましょう。

CSS側

input {
  display: none;
}

img:hover {
  opacity: 0.7;
}

#error {
  color: red;
}

特筆すべき点はないですが、imgにhoverしたら透明度を上げるようにしてクリック判定をわかりやすくしてます。

コンポーネント・モジュール可する

せっかく作ったフォームなので、コンポーネントにして取扱いを良くしたり、他で使いそうなメソッドはモジュール化した方がいいかもしれません。（設計に関する一番むずかしいところ…）

とりあえず自分は、以下のように親子関係を作ってみました。

親側のフォーム

<label>
  <img class="w-24 h-24 rounded-full mr-4 bg-hover" v-lazy="avatar" alt="Avatar">
  <UserImageUploader
    v-bind="user"
    :params="{ limit: 1000, unit: 'kb', allow: 'jpg,png' }"
    v-model="avatar"
   />
</label>

3行目が子コンポーネントです。(UserImageUploader)。親側で呼び出すときに必要なデータをバインドして子供側で扱えるようにしてます。

今回の場合だと、ユーザー情報、バリデーション情報、画像情報を渡してます。

子供側(コンポーネント名：UserImageUploader)

<template>
  <div>
    <p id="error" v-show="error">{{ error }}</p>
      <div class="m-6">
        <input
          type="file"
          id="avatar_name"
          class="input_image"
          accept="image/jpeg, image/png"
          @change="onImageChange"
        />
      </div>
  </div>
</template>

<script>
import { FileEvaluable } from '@/components/mixins/FileEvaluable'
export default {
  name: 'UserImageUploder',
  mixins: [ FileEvaluable ],
  props: {
    id: Number,
    currentImage: String
  },
  model: {
    // このcurrentImageは親で指定した(v-model="avatar")と同値。
    prop: 'currentImage',
    event: 'change'
  },
  data () {
    return {
      message: '',
      error: ''
    }
  },
  methods: {
    setError (error, text) {
      this.error = (error.response && error.response.data && error.response.data.error) || text
    },
    getBase64 (file) {
      return new Promise((resolve, reject) => {
        const reader = new FileReader()
        reader.readAsDataURL(file)
        reader.onload = () => resolve(reader.result)
        reader.onerror = error => reject(error)
      })
    },
    setImage (currentImage) {
      this.$emit('change', currentImage)
    },
    onImageChange (e) {
      const images = e.target.files || e.dataTransfer.files
      if (this.validation(images[0])) {
        this.getBase64(images[0])
          .then(image => this.setImage(image))
          .catch(error => this.setError(error, '画像のアップロードに失敗しました。'))
      } else {
      }
    },
    validation (file) {
      if (!this.isAllowFileType(file.type)) {
        this.error = this.getErrorMessageType()
        this.canBeUploaded = false
        return false
      }
      if (!this.isAllowFileSize(file.size)) {
        this.error = this.getErrorMessageSize()
        this.canBeUploaded = false
        return false
      }
      this.error = ''
      this.canBeUploaded = true
      return true
    }
  }
}
</script>

<style scoped>
.input_image {
  display: none;
}
</style>

読みづらいですが、propだったりmodelだったりで、親からバインドされた値を受け取ってます。

子供側でmixinsされてるモジュールは、今回の記事とは関係ないバリデーション処理のものですが、わざわざ取り除くのも大変だったのでべた張りしました。

機能としての改善点としては、プレビューの画像サイズが今のままだとユーザー依存なのでそれを変更したり、選択した画像の一部分だけ使うよう編集できる機能についても必要かな、と思いますが、長くなりますので今回はここまでとします。

余談

画像の送信方法について、最初はBase64エンコードを使わず、JSにおけるFormData型の画像を「Content-Type: multipart/form-data」でバックエンドに送る方式をとっていました。ただ、自分がバックエンドで使用しているRailsAPIとのかみ合わせが悪く、リクエストではファイルをそのまま受け取れるものの、レスポンスにおいてはJSONじゃないファイル型を返せるコントローラーを新たに作ったりする必要がある(ActionController::APIを継承したコントローラじゃファイルをrender出来ない。)というデメリットがあり、一度実装してみたものの、取り回しが悪そうなので削除しました。

（こういうの実装する前に気づけるようになりてえ〜）

ちなみに、Railsでは受け取ったエンコード済み画像をデコードしてFileオブジェクトに戻し、それをAWSのS3に保存してます。

その処理もまた後にブログにするかもしれません。（しないかもしれない！　読みたい方がいたら書きます）

おしまい。

続編

fujiten3.hatenablog.com

fujiten3.hatenablog.com

Dockerの基礎

自分用です。

コマンド：

// dockerバージョンのチェック
docker version

// dockerの情報を詳しく知る
docker info

// dockerコマンドの一覧表示
docker

// imageをインストール
docker pull <任意のimage>

// インストールしているimageの詳細情報を確認する
docker image inspect <image名>

imageは動かしたいアプリケーションの設定。コンテナはそれに従って動く。

同じimageを共有し、複数のコンテナを動かせる。

以下はnginxイメージに則ったコンテナを起動する例。

docker container run --publish 80:80 nginx

1. nginxをDockerHubから入手
2. imageから新たなコンテナを起動
3. port80をHostIPとして開く
4. 80へのアクセスをcontainerのポートである80へとつなぐ。(8080:80 なら　8080をコンテナの80につなぐ)

--detachオプションをつければ、バックグラウンドで起動できる。

docker container run --publish 80:80 --detach nginx

止めたいときは、ユニークIDを指定しながら、stopすればいい。

//起動しているコンテナの確認
docker container ls 

// ユニークIDは最初の数文字で大丈夫
docker container stop f60 

runは新たなコンテナの起動。startは一度止めたコンテナの再起動。

// コンテナのログの確認(detach等でバックグランド起動したときはこれでログを確認できる)
docker container logs <container's name>

dockerコンテナに関するコマンドを見たいときは、以下。

docker container --help

例えばtopコマンドは、コンテナのpidを確認できる。

邪魔なコンテナは以下で削除。

docker container rm <UID>

コンテナはただのプロセスである

仮想マシンとの違いはそこ。

//起動しているすべてのコンテナのパフォーマンスを調べられる(消費しているリソース量など)
docker container stats 

//起動しているコンテナを指定すると、設定詳細が確認できる(JSON形式)
docker container inspect

//イメージに基づき、インタラクティブにコンテナを起動できる(exitで脱出)
docker container run -it <Container's name> bash

//脱出したあと、また潜るためには以下。
docker container start -ai <Container's name>

//すでに起動しているコンテナについて、bashで潜れる
docker container exec -it <Container's name> bash

ネットワークについて。

// Dockerが保持しているnetworkの参照
docker network ls

// networkの深掘り
docker network inspect <network's name>

//ネットワーク同士の接続
docker network connect <network1> <network2>

静的なIPを設定したり、IPを使ってコンテナに接続しにかかるのはアンチパターン。コンテナの名前を使おう。

イメージについて

アプリケーションバイナリと、依存関係のこと。OSやカーネルやカーネルモジュールは準備しない。

イメージはdocker.hubで確認できる。公式のものはドキュメントが詳細に書かれている。ただ、公式より人気のものがあったりするので、その理由を確認するものよい。

イメージレイヤとは

イメージはファイルシステムとメタデータ。イメージのそれぞれのレイヤーはホストに一度だけ保存され、それは流用される。コンテナはイメージレイヤの最上部に位置される読み書き可能な単一のレイヤーである。historyコマンドやinspectコマンドで、イメージの詳細について調べられる。

Dockerfileの作り方

FROMから始まり、Dockerhubにあるイメージを選択する。

ENVで環境変数を設定する。

RUNはシェルコマンド。パッケージレポジトリを利用してファイルをインストールすることができる。

EXPOSEは仮想ネットワークに公開するポート番号。

CMDはイメージから新しいコンテナを起動するさいや、コンテナの再起動の際に実行される最後のコマンド。

DockerFileはキャッシュを使いビルドを高速化しているので、Dockerfile内のコード変更は出来る限り下部のものを多く変更するようにしたほうが、処理が高速化する。（上部を変更すると、下部はキャッシュを使えず、新たにビルドする）

コンテナについて

コンテナは不変だが、長く保持されるものではない。

データベースやユニークデータを保持するためには、永続データとして保持する必要があり、そのための方法として以下の２つのものがある。

• Volumes 　コンテナのユニークファイルシステムの外部に特別なロケーションを設定し、そこに保持する。
• Bind Mounts　ホストディレクトリをコンテナ内にマウントしておく。

Volumeについて：Dockerfileにて、VOLUMEコマンドを使えば、Volumes先を指定できるが、コンテナが削除されても保持されているため、削除したい場合は手動で削除する必要がある。

コンテナ起動の際に、docker container run -v :mysql/var/libといった形で指定すれば、docker volume ls コマンドでVolumeNameを確認した際、ほかのボリュームと判別しやすい。（また、同じドライバ（Mysql)だが異なるコンテナを起動したさい、このように指定しておかないと、ドライバがそれぞれ別のボリュームを作成する。）

Bind Mountsについて：ホストのファイルやディレクトリをコンテナ内にマッピングする。基本的にそれらは同じ場所を指している。マッピングしたさい、ホストファイリルがコンテナ内のファイルを上書きする（同場所にあった場合）。Dockerfile内で使用することができず、「docker container run -v $(pwd):/usr/share/nginx/html」といった形で指定する。このコマンドを使うと、ホストの現在のワーキングディレクトリ内の内容を、コンテナ内の/usr/share/nginx/htmlにマッピングされ続ける。（確認したい場合は、「docker container exec -it nginx bash」を使い、bashを使って内部に潜り込んでみよう。）

Docker compose について

compose.ymlに基づいてコンテナ同士の関係を作る。

公式ドキュメントを見ると詳細が載っているので、困ったときは参照しよう。 Compose file version 3 reference | Docker Documentation

docker-compose CLIは、本番環境上よりも、「開発環境とテスト環境」において力を発揮する。

もっとも基本的なコマンドは以下。

//volumesとnetworksをセットアップし、すべてのコンテナを起動する。
docker-compose up

//すべてのコンテナを止め、コンテナとボリュームとネットワークを削除する。
docker-compose down

docker-compose ps

docker-compose logs

// 現在起動しているコンテナのPIDやUserを表示する
docker-compose top

Ruby on Railsガイドを通読してまとめる Part.4

第四弾です。

コントローラー

Action Controller の概要

リクエストを受け取るコントローラーがルーティングによって指名されると、コントローラーはリクエストの意味を理解し、適切な出力を行うための責任を持つ。

これらの一連の処理はAction Controllerによって保証されている。

パラメータ(4)

一般的なWebアプリケーションと同じく、Railsでも2種類のパラメータが受け取れる

• URLの一部としてのクエリ文字列(GET)
• POSTデータ

JSONパラメータ(4.2)

リクエストのcontent-typeに「application/json」が指定されていたら、RailsはJSONコンテンツを受け取れる。

# このJSONコンテンツは
{ "company": { "name": "acme", "address": "123 Carrot Street" } }

# パラメータでこう受け取れる
params[:company] => { "name" => "acme", "address" => "123 Carrot Street" }

ストロングパラメーター(4.5)

マスアサインメントを防ぐ技術。詳細は何度も出てくるので省略。

Strong Parametersのスコープの外のものをホワイトリスト可（許可）するコードとして、以下のようなものがある。

def product_params
  params.require(:product).permit(:name, data: params[:product][:data].try(:keys))
end

data: でスコープ外のものを指定。.try(:keys)で、中身のキーを取り出して許可、という挙動かな。

セッション(5)

セッションは遅延読み込みなので、アクセスしなかったら無効であるのと変わらない。

class ApplicationController < ActionController::Base
 
  private
 
  # キー付きのセッションに保存されたidでユーザーを検索する
  # :current_user_id はRailsアプリケーションでユーザーログインを扱う際の定番の方法。
  # ログインするとセッション値が設定され、
  # ログアウトするとセッション値が削除される。
  def current_user
    @_current_user ||= session[:current_user_id] &&
      User.find_by(id: session[:current_user_id])
  end
end

session[:current_user_id]に値があるときだけ現在のユーザーを返すというメソッドの基本形。

Flash(5.2)

redirect_toにわたすことも出来る。

redirect_to root_url, notice: "You have successfully logged out."
redirect_to root_url, alert: "You're stuck here!"
redirect_to root_url, flash: { referral_code: 1234 }

flashは通常、次のリクエストまでしか持たないが、keepメソッドを使用することで、保たせることが可能。

class MainController < ApplicationController
  # このアクションはroot_urlに対応しており、このアクションに対する
  # すべてのリクエストをUsersController#indexにリダイレクトしたいとします。
  # あるアクションでflashを設定してこのindexアクションにリダイレクトすると、
  # 別のリダイレクトが発生した場合にはflashは消えてしまいます。
  # ここで'keep'を使うと別のリクエストでflashが消えないようになります。
  def index
    # すべてのflash値を保持する
    flash.keep
 
    # キーを指定して値を保持することもできる
    # flash.keep(:notice)
    redirect_to users_url
  end
end

flash.nowを使えば、そのリクエストへのレンダーで評価できる。(リダイレクトで他のところに渡す場合はnowをつけない)

Cookie(6)

セッションのようにアクセス出来る。クッキーの保持期間などを設定できるらしい。

class CookiesController < ApplicationController
  def set_cookie
    cookies.encrypted[:expiration_date] = Date.tomorrow # => Thu, 20 Mar 2014
    redirect_to action: 'read_cookie'
  end
 
  def read_cookie
    cookies.encrypted[:expiration_date] # => "2014-03-20"
  end
end

クッキーの中身はユーザーごとに、ローカルにおけるそのブラウザのクッキーフォルダに保存される。

Chromeの場合はSQlite型でローカルに保存しているので、直接中身を見に行っても読み取ることは無理。(1敗)

調べた所、「Set-Cookie: クッキー名=クッキー値; expires=有効期限; domain=ドメイン名（サーバ名）; path=パス; secure」というレスポンスヘッダーでクッキーをユーザーに保存させられるそう。

secureはSSL/TLS通信のときのみそのクッキーを使用するように強制する。

フィルタ(8)

before_action, after_action, around_action といったもの。

# こう設定すれば、特定のコントローラーの特定のアクションでフィルタをスキップできる
skip_before_action :require_login, only: %i(new create)

around系は、yieldで評価することで、そのアクションを実行する。

class ChangesController < ApplicationController
  around_action :wrap_in_transaction, only: :show
 
  private
 
  def wrap_in_transaction
    ActiveRecord::Base.transaction do
      begin
        yield
      ensure
        raise ActiveRecord::Rollback
      end
    end
  end
end

リクエストフォージェリからの保護(9)

CSRFからアプリケーションを守る。forgeryは「偽造」という意味。

railsではformヘルパーが自動的にトークンを作ってくれる。

ただ、フォームヘルパーを使わないケース（RailsAPI）も増えてると思うので、そのときはおそらく別の何かを用意すると思われる。

requestオブジェクト(10.1)

requestオブジェクトはリクエストに関する情報を内包している。host,domain,formatなどを使って、その内容を読み取ることが可能。

requestのパラメータに関する情報はparamsハッシュに集約してくれている。

responseオブジェクト(10.2)

responseオブジェクトはアクションが実行されるときにビルドされ、クライアントに送り返されるデータをレンダリングするため、通常はアクセスしない。

ただ、「after系」フィルタで参照できるため、セッターメソッドがあれば値を代入できる。

HTTPダイジェスト認証

https化していない状態のBASIC認証はパスワードを平文で送る。それを避けたい場合は、HTTPダイジェスト認証を使う手がある。

class AdminsController < ApplicationController
  USERS = { "lifo" => "world" }
 
  before_action :authenticate
 
  private
 
    def authenticate
      authenticate_or_request_with_http_digest do |username|
        USERS[username]
      end
    end
end

USERSという定数に「ユーザー名 => パスワード」のハッシュを与える、あとは認証のさいに入力するだけ。

ストリーミングとファイルダウンロード(12)

send_dataメソッドを使うと、クライアントにファイルをストリーミング送信できる。

サーバー上にすでにあるファイルを送りたい場合は、send_fileメソッド。ただし、Rails経由でストリーミング送信するより、Webサーバーのpublicフォルダに置いてダウンロードさせるほうがよい。

ログフィルタのカスタマイズ(14)

パラメータとリダイレクのフィルタ

# パラメータのフィルタ
config.filter_parameters << :password

# リダイレクトのフィルタ
config.filter_redirect << 's3.amazonaws.com'

パラメータのフィルタのケースは、/password/にマッチするとフィルタされる。なのでparams[:password_confirmation]の中身もフィルタ対象。

リダイレクト先のフィルタは300返したあとのlocationについてログに出さない。ヘッダーのlocationを読まれたら無意味な気もするが…。

Rescue(14)

例外ハンドリングを行い、適切なステータスを返したり、処理を行う。

rescue_fromを使えば、特定の例外（カスタム例外クラスを含む）に対して、柔軟に対応できる。

class ApplicationController < ActionController::Base
  # カスタム例外が起きたときに、with:以下のメソッドで対応
  rescue_from User::NotAuthorized, with: :user_not_authorized
 
  private
 
    def user_not_authorized
      flash[:error] = "You don't have access to this section."
      # 認証失敗した場合は、前の画面またはルートに戻る。
      redirect_back(fallback_location: root_path)
    end
end
 
class ClientsController < ApplicationController
  # ユーザーがクライアントにアクセスする権限を持っているかどうかをチェックする
  before_action :check_authorization
 
  # このアクション内で認証周りを心配する必要がない
  def edit
    @client = Client.find(params[:id])
  end
 
  private
 
    # ユーザーが認証されていない場合は単に例外をスローする
    def check_authorization
      raise User::NotAuthorized unless current_user.admin?
    end
end

Railsのルーティング

Railsルーターの目的(1)

受け取ったURLを認識し、適切なアクションやRackアプリケーションに割り当てる。

浅いネスト(2.7.2)

ネストを深くしすぎるとURLが読みづらい。そこで、コレクション(index/new/createのようなidを持たないアクション）だけを、親のスコープで生成する方法がある。

:shallow オプションを付ける。

resources :articles do
  resources :comments, shallow: true
end

# 上の:shallowオプションが付いているものと同義
resources :articles do
  resources :comments, only: [:index, :new, :create]
end
resources :comments, only: [:show, :edit, :update, :destroy]

concernでの共通化(2.8)

ネストさせるルートに名前をつけておくような機能。

concern :commentable do
  resources :comments
end
 
concern :image_attachable do
  resources :images, only: :index
end

上で定めたconcernを

resources :messages, concerns: :commentable
 
resources :articles, concerns: [:commentable, :image_attachable]

というように使える。

memberルーティングを追加する(2.10.1)

:idをもらいながらそのコントローラにルーティングを追加したいときは

# params[:id]で取れる
resources :photos do
  member do
    get 'preview'
  end
end

# この場合はparams[:photo_id]で取る
resources :photos do
  get 'preview', on: :member
end

collectionでのルーティングはmenberと似ているが、:idをパスに置かない。

デフォルト設定を定義する(3.5)

defaults: { format: 'hoge' } でリクエストのフォーマットを定義できる。

get 'photos/:id', to: 'photos#show', defaults: { format: 'jpg' }

photos/3はphotos/3.jpgというパスでのリクエストと解釈する

セグメントを制限する(3.8)

:constraintsオプションによりセグメント(:id)の値を制限できる。

get 'photos/:id', to: 'photos#show', constraints: { id: /[A-Z]\d{5}/ }

高度な制限(3.10)

特定ユーザーのIPをブラックリストに入れ、ブラックリストIPはサイトに入れない設定。

matches?(request)に応答できるオブジェクトを渡せば、それを実行し、trueを返したときのみ特定のコントローラーに誘導できる。

class BlacklistConstraint
  def initialize
    @ips = Blacklist.retrieve_ips
  end
 
  def matches?(request)
    @ips.include?(request.remote_ip)
  end
end
 
Rails.application.routes.draw do
  get '*path', to: 'blacklist#index',
    constraints: BlacklistConstraint.new
end

リソースフルに制限を指定する(4.2)

/photos/:id の:idについて、constraintsに正規表現を渡すことで制限する。

resources :photos, constraints: {id: /[A-Z][A-Z][0-9]+/}

感想

とりあえず、「基礎部分」については、全て読みきりました。

クエリ発行のところが一番おもしろかったです。

Ruby on Railsガイドを通読してまとめる Part.3

第三弾です。前回はこちら。Ruby on Railsガイドを通読してまとめる Part.2 - エンジニア備忘録

railsguides.jp

なんだかんだPart.3まで続けられました。

これもひとえに自分の努力の成果です。自分すげえ。（ただまとめてるだけなので大した努力ではない）

読みやすいようにまとめたいと思うんですが、やはり量が膨大になってしまうので、さらっと流し見して気になるところがあれば本家Railsガイドさんを読んでいただければと思います。

モデル

ActiveRecord クエリインターフェイス

Active Recordは、ユーザーに代わってデータベースにクエリを発行できる。勉強初期の頃は全くピンとこない概念。（今は何とかわかる）

発行されるクエリは多くのデータベースシステム (MySQL、MariaDB、PostgreSQL、SQLiteなど) と互換性がある。

ActiveRecordはORマッパーとしてとても評判がいい。(と聞いたことがある。ソースはないです)

以下、様々なメソッドについての説明。

DBからオブジェクトを取り出す(1)

ActiveRecord::Baseを継承したクラスからオブジェクトを取り出すためのメソッド。たくさんありますね。

find
create_with
distinct
eager_load
extending
from
group
having
includes
joins
left_outer_joins
limit
lock
none
offset
order
preload
readonly
references
reorder
reverse_order
select
where

気になったやつだけ抜粋。

単一のオブジェクトを取り出す(1.1)

take

ランダムに1つ取り出す。（例：Client.take）

SQLとしては以下。

SELECT * FROM clients LIMIT 1

take(2)といった形にすれば取り出す数を増やせる。

firstとかはこのSQLにORDER BY idついてるだけなので、そっちでもいい。

（idにインデックス貼ってないことはないだろしtakeとfirstで早さほぼ変わらないはず）

複数のオブジェクトをバッチで取り出す(1.2)

find_each

DBから取り出したデータをメモリを圧迫しないサイズにして、ブロック引数に「取り出したレコード１つ」を格納して処理する。

User.find_each do |user|
  NewsMailer.weekly(user).deliver_now
end

デフォルトでは1000件がバッチとなり、|user|に1つずつレコードが格納されている(はじめに1000回繰り返し、終わったら次。）

オプションによってバッチとする件数を3000とかにカスタマイズ出来たり、どのidからどのidまでで処理を止めるか設定できる。

find_in_batches

DBから取り出したデータをメモリを圧迫しないサイズにして、ブロック引数に「取り出したレコード全て」を格納して処理する。

# 1回あたりadd_invoicesに納品書1000通の配列を渡す
Invoice.find_in_batches do |invoices|
  export.add_invoices(invoices)
end

invoicesというブロック引数に1000件分のレコードが詰まっている。その1000件分の情報はたぶんActiveRecord::Relationオブジェクトという形にして保持されていると思うけど、書いていないので詳細は謎。

気になる人は調べてね！　

文字列だけで表した条件で取り出す(2.1)

SQLインジェクションを発生させないため、パラメーターを使うときは配列(?を使った表現)を使用しましょう。

Client.where("orders_count = ?", params[:orders])

パラメータを使わないなら可読性上げるために文字列でもいいと思います。

プレースホルダーを使用した条件で取り出す(2.2.1)

配列（引数の順番で渡す）以外にも、ハッシュを使える。

Client.where("created_at >= :start_date AND created_at <= :end_date",
  {start_date: params[:start_date], end_date: params[:end_date]})

読みづらくね？

条件の上書き(8)

unscope

条件を外せる。カスタムしたスコープから一つだけ条件外したいときとかに使うのかな？

Article.where('id > 10').limit(20).order('id asc').unscope(:order)

reorder

デフォルトスコープの並び順を上書きできる。

class Article < ApplicationRecord
  has_many :comments, -> { order('posted_at DESC') }
end
 
Article.find(10).comments.reorder('name')

#上書きしたSQL
SELECT * FROM articles WHERE id = 10
SELECT * FROM comments WHERE article_id = 10 ORDER BY name

#上書きする前のSQL

SELECT * FROM articles WHERE id = 10
SELECT * FROM comments WHERE article_id = 10 ORDER BY posted_at DESC

基本unscopeでいけそうだけど、デフォルトスコープに他の条件がたくさんあってorderだけ変えたいときに使える。（あるのか？）

Nullリレーション

noneメソッドはチェイン可能なリレーションオブジェクトを生み出すことができる。

# visible_articles メソッドはリレーションを返すことが期待されている
@articles = current_user.visible_articles.where(name: params[:name])
 
def visible_articles
  case role
  when 'Country Manager'
    Article.where(country: country)
  when 'Reviewer'
    Article.published
  when 'Bad User'
    Article.none # => []またはnilを返すと、このコード例では呼び出し元のコードを壊してしまう
  end
end

nilじゃなくてActiveRecord::Relation(中身無し)を返したいときに使う。便利そう。

楽観的ロック(optimistic lock)(11.1)

複数のユーザーが同じレコードを編集することを認める。 このロックを使用するためには、テーブルに「lock_version」という名前のInteger型カラムが必要である。

レコードが更新されるたび、lock_versionカラムの数値が1ずつ増える。 ユーザーがレコードを更新するとき、DBのlock_versionが自分が編集しているlock_versionより大きかったらエラー。

楽観的と言うとるわりに普通にエラーは出す。

悲観的ロック(pessinistic lock)(11.2)

DBのロック機構を使用する。 絶対に他のユーザーにUPDATEさせないという前提のもと、「読み出し許可」するかしないか設定できる。

# MySQLの場合は、lockメソッドに「LOCK IN SHARE MODE」を与えれば読み出しは許可できる。
Item.transaction do
  i = Item.lock("LOCK IN SHARE MODE").find(1)
  i.increment!(:views)
end

たくさんのユーザーが１つのリソースを触るんじゃなく、決まったチームメンバーが１つのリソースを丁寧に時間かけて編集するときは悲観的ロックのほうが親切だろう。（楽観的ロックだと「え？hogeさんも編集してたんすか？あーだったら俺は編集しなかったのに」みたいなのが起き得る）

joinによる結合(12)

内部結合。SQL文を引数に渡すこともできるが、関連付けしてあれば結合クエリを簡単に作れる。

left_outer_joins

外部結合。関連レコードがない場合でもレコードをセットを取得できる。

関連付けを一括読込する(13)

eager loading！　ググってもはっきり出てこないやつ。

日本語には「一括読み込み」と訳すようですね。

N+1クエリ問題を解決する

includeで予め読み込んでおく解決策

clients = Client.includes(:address).limit(10)
 
clients.each do |client|
  puts client.address.postcode
end

この場合は、addressesテーブルの外部キーをINで指定しておくことで、先に読み込んでいるようです。

SELECT * FROM clients LIMIT 10
SELECT addresses.* FROM addresses
  WHERE (addresses.client_id IN (1,2,3,4,5,6,7,8,9,10))

複数の関連付けを予め読み込む(13.1)

2つ引数を指定すればオーケー。

Article.includes(:category, :comments)

ネストした関連付けハッシュ(13.1.2)

Category.includes(articles: [{ comments: :guest }, :tags]).find(1)

上のコードは、id=1のカテゴリを検索し、関連付けられたすべての記事とそのタグやコメント、およびすべてのコメントのゲスト関連付けを一括読み込みする。

「先の先」を取りに行く場合は、ハッシュ構造を使うということですね。「Category.include({article: commets})」で、「categoryに紐づくarticlesを全てとる。そして取ってきたarticleにcommentsを紐づけておく」という動き。

関連付けの一括読み込みで条件を指定する(13.2)

ガイドに書いてあった日本語が難解だった。

「Active Recordでは、joinsのように事前読み込みされた関連付けに対して条件を指定することができますが、joins という方法を使用することをお勧めします。」とのこと。

おそらく意図は「通常、内部結合しにかかりたいならjoinsを使うのが一番いい」ってことかな…？

ただjoin使ってダメなときはincludesにwhereを使って外部結合表現することも可能、とのこと。

Article.includes(:comments).where(comments: { visible: true })

上のコードは下のクエリを発行する。外部結合していますね。

SELECT "articles"."id" AS t0_r0, ... "comments"."updated_at" AS t1_r5 
FROM "articles" 
LEFT OUTER JOIN "comments" ON "comments"."article_id" = "articles"."id" 
WHERE (comments.visible = 1)

ハッシュを渡さず文字列でwhereの条件を指定した時、リファレンスを指定して強制的にテーブルをjoinし、SQL断片化を防ぐ必要があるとのこと。

Article.includes(:comments).where("comments.visible = true").references(:comments)

SQL断片化…ってなにって思って調べてもよくわからん…。親が消えたのに残った外部キーのインデックスのことですかねえ。

そしてreferences(:commnets)を付けることでクエリにどう変化がうまれるのかサッパリ。

ここは宿題にさせて下さい（涙目）

スコープ(14)

scopeメソッドにシンボルとlambdaブロックを渡すことで、カスタムクエリ（スコープ）を作れる。

条件を組み合わせてあなただけのクエリを発行しよう！

class Article < ApplicationRecord
  scope :published, -> { where(published: true) }
end

上のコードは、下と同義らしいです。

class Article < ApplicationRecord
  def self.published
    where(published: true)
  end
end

つまりscopeなんてかっこつけたところで本質は「ただのクラスメソッド」ってことですね！！なんだビビらせやがって…。（ただ、戻り値の観点で少し差が生まれることがある。少し下の#14.2参照）

スコープ内でスコープをチェインすることも可能。

引数を渡す(14.1)

scopeでも引数を渡せるらしい。

class Article < ApplicationRecord
  scope :created_before, ->(time) { where("created_at < ?", time) }
end

ただ引数を渡す場合は、クラスメソッドとして定義することが推奨されているだとか。「scopeはクラスメソッドを複製した機能である」ということを強調するためらしいですが、scopeの方が明示的に「クエリ用」ってわかりやすいから、こっちでも良い気がしますけど、どうなんでしょう。

条件文を使う(14.2)

scopeとクラスメソッドで挙動が違う。

# これの戻り値は常に「ActiveRecord::Relationオブジェクト」
class Article < ApplicationRecord
  scope :created_before, ->(time) { where("created_at < ?", time) if time.present? }
end

# これは条件が「false」のとき、戻り値はnil
class Article < ApplicationRecord
  def self.created_before(time)
    where("created_at < ?", time) if time.present?
  end
end

デフォルトスコープ(14.3)

前回の記事で、「関連付けのさいの（相手側への）デフォルトスコープ」を学んだが、これは「自分に設定するデフォルトスコープ」

class Client < ApplicationRecord
  default_scope { where("removed_at IS NULL") }
end

こうすると、このモデルへのクエリに「WHERE removed_at IS NULL」がデフォルトで設定される。

デフォルトスコープの条件を複雑に設定したいなら、「self.default_scope」で定義してもOK。

スコープの解除(14.5)

デフォルトスコープ等を完全に解除したいときはunscopedしましょう。

Client.unscoped.all
# SELECT "clients".* FROM "clients"
 
Client.where(published: false).unscoped.all
# SELECT "clients".* FROM "clients"

大事なことなので２回言いました。

Enums(16)

整数型のカラムを設定可能な値の集合にマッピングしてくれる上に、対応するスコープまで自動的に作成してくれる。

class Book < ApplicationRecord
  enum availability: [:available, :unavailable]
end

0で:available、1で:unavailable。

メソッドの例が以下。

# 下の両方の例で、利用可能な本を問い合わせている
Book.available
# または
Book.where(availability: :available)
 
book = Book.new(availability: :available)
book.available?   # => true
book.unavailable! # => true
book.available?   # => false

詳細はRailsAPIへ！

ActiveRecord::Enum

メソッド

find_or_create_by(18.1)

レコードを検索し、なければ作成するメソッド。

レコード作成時の各カラムの値については、ブロックを渡すか、create_withメソッドでの指定で対応できる。ブロックのほうが勝手が効きそうなので、こちらだけ紹介。

Client.find_or_create_by(first_name: 'Andy') do |c|
  c.locked = false
end

Clientモデルのlockedカラムをfalseにする処理ができます。

find_or_initialize_by

レコードを検索し、なければ「new」でインスタンスを作成するメソッド。保存処理はしない。

find_by_sql

引数に文字列を渡すと、それをSQLとして実行してくれる。戻り値は常に配列（内部にオブジェクト格納）

select_all

引数のSQLを実行し、結果としてActiveRecord::Resultオブジェクトを返す。to_hashを打つとハッシュが格納された配列が得られる。

pluck

英語の意味は「摘む」。

テーブルから特定のカラムの値だけを配列等で取り出したいときに使える。

mapなどで無理やり取り出すより、pluckで取り出したほうがパフォーマンスが優れている。

Client.select(:id).map { |c| c.id }
# または
Client.select(:id).map(&:id)
# または
Client.select(:id, :name).map { |c| [c.id, c.name] }

上の例はAvtiveRecordオブジェクトへの#mapだが、下のようにpluckを使えば、ActiveRecordオブジェクトを準備しなくてもいいし、その上スマートに書ける。最高ですね。

Client.pluck(:id)
# または
Client.pluck(:id, :name)

ただし、オブジェクトを介していないため、オーバーライドは出来ない。

class Client < ApplicationRecord
  def name
    "私は#{super}"
  end
end
 
# Client.select(:name)で、Clientクラスのインスタンスが生まれている。それにnameを打つためオーバーライド出来る。
Client.select(:name).map &:name
# => ["私はDavid", "私はJeremy", "私はJose"]
 
# pluckはインスタンス作成を行わない。
Client.pluck(:name)
# => ["David", "Jeremy", "Jose"]

他にも、あくまで配列で取り出すため、limitなどを打つことはできないといった注意点がある。

# Arrayにlimitは打てない
Client.pluck(:name).limit(1)
# => NoMethodError: undefined method `limit' for #<Array:0x007ff34d3ad6d8>
 
# 先にlimitしてればOK
Client.limit(1).pluck(:name)
# => ["David"]

exists?

引数がDBに存在するか調べる。1つでもあればtrue、なければfalse

ライバルとして「present?」、「any?」が存在する。そしてそれぞれパフォーマンスが異なるそう。

そして「そのスコープによって検索に引っかかるレコードが存在するか？」という条件分岐だけをしたい際は、下の記事いわくパフォーマンス最強が「exists?」とのこと。

参考記事： Present? Vs Any? Vs Exists? - The Lean Software Boutique

この参考記事だとpresent?は内部結合したあと、レコード自体を取得しにいってるので、「存在するかどうか」だけを調べる場合パフォーマンスが悪いとのこと。

any?、exists?は内部結合するところまでは同じだけど、COUNT(*)でレコード数を取りに言ってるのでパフォーマンス的にpresent?に勝ってる。記事ではany?はLIMIT(1)を付けてないのでその分遅いらしいが、調べてたらRails5.2（?）からLimit付けてて同着らしい。どっちや。

ここまできたら内部のコード見に行った方がいいけどActiveRecord潜りにいく元気は今はねえ！！　ということで、これも要検証認定です。おめでとう！！

count, average, minimum, maximum, sum(21)

SQLの集計関数を呼び出す者たち。

EXPLAIN

explainメソッドにより、標準出力などで以下のようなものが得られる

# これを打てば…
User.where(id: 1).joins(:articles).explain

↓が得られるそうです

EXPLAIN for: SELECT `users`.* FROM `users` INNER JOIN `articles` ON `articles`.`user_id` = `users`.`id` WHERE `users`.`id` = 1
+----+-------------+----------+-------+---------------+
| id | select_type | table    | type  | possible_keys |
+----+-------------+----------+-------+---------------+
|  1 | SIMPLE      | users    | const | PRIMARY       |
|  1 | SIMPLE      | articles | ALL   | NULL          |
+----+-------------+----------+-------+---------------+
+---------+---------+-------+------+-------------+
| key     | key_len | ref   | rows | Extra       |
+---------+---------+-------+------+-------------+
| PRIMARY | 4       | const |    1 |             |
| NULL    | NULL    | NULL  |    1 | Using where |
+---------+---------+-------+------+-------------+
 
2 rows in set (0.00 sec)

使うのかな…？

ビュー

ActionViewの概要

ビュー生成を担当するライブラリ。

Jbuilder(3.1.3)

Railsにデフォルトで含まれるGemの1つ。JSONを生成するのに使用する。

.jbuilderという拡張子を持つテンプレートでは、jsonという名前のJbuilderオブジェクトが自動的に利用できるようになる。

詳しい挙動は公式ドキュメントで。

GitHub - rails/jbuilder: Jbuilder: generate JSON objects with a Builder-style DSL

パーシャルレイアウト(4)

全体のレイアウトとは異なり、ローカル変数を渡せる。パーシャルテンプレートをyieldで評価しながらテンプレートを作る。

articles/show.html.erb

<%= render partial: 'article', layout: 'box', locals: { article: @article } %>

artcicles/_box.html.erb

<div class='box'>
  <%= yield %>
</div>

これでパーシャルテンプレートである_articleを、パーシャルレイアウトである_box内で使ってテンプレートを作成できる。

ActionViewのヘルパーメソッド(6)

大量にありますが、必要に応じて参照すれば良さそうです。（Rails側でテンプレートを作る技術が、今後フロントエンドのフレームワークに置き換わっていく可能性も考え、ここは一旦スルーします。）

レイアウトとレンダリング

コントローラからビューへの結果の渡し方について解説するトピック。

レスポンスを作成する(2)

コントローラー側から見ると、HTTPレスポンスの作成方法は以下の3通り。

• renderを呼び出し、ブラウザに返す完全なレスポンスを作成する
• redirect_toを呼び出し、HTTPリダイレクトコードステータスをブラウザに送信する
• headを呼び出し、HTTPヘッダーのみで構成されたレスポンスを作成してブラウザに送信する

設定より規約(2.1)

コントローラーはrenderを指定しなくても命名規則に従ったものをrenderする。

そういえば、この規約って、「convention」の訳だと思うんですが、どちらかと言えば「慣習」という意図のほうが意図にマッチしてる気がする

別のコントローラからアクションのテンプレートを出力する(2.2.1)

app/views以下のパスを指定すればOK

render "products/show"

appディレクトリ外のテンプレートを使いたい場合は、"/"から始まるフルパスで指定する。

renderのオプション(2.2.12)

以下の5つが一般的。

• content_type
• layout
• location
• status
• formats

content_type

レスポンスのcontent-typeを指定できる。:jsonを渡せば、application/json、:xmlを渡せばapplication/mlなど。

layout

現在のアクションに対して、特定のファイルをレイアウト指定できる。

出力時に、デフォルトのレイアウトを使用しないよう設定も可能。

render layout :false

location

HTTPのlocationヘッダーを設定できる。300などで飛ばす場所のこと。

render xml: photo, location: photo_url(photo)

status

HTTPステータスコードを明示的に指定したい場合に使用する。

formats

リクエストで指定されたフォーマットに応じてレスポンスを返す。

render formats: [:json, :xml]

レイアウトの探索経路(2.2.13)

レイアウトの探索経路は、「そのコントローラ管轄のviewsにlayoutディレクトリがあるか探し、なければ共通のレイアウトを使用する」という流れです。

たとえば、PhotosControllerクラスのアクションから出力するのであれば、app/views/layouts/photos.html.erbまたはapp/views/layouts/photos.builderを探します。該当のコントローラに属するレイアウトがない場合、app/views/layouts/application.html.erbまたはapp/views/layouts/application.builderを使用します。

設定次第で、任意のレイアウトを指定できる。

例えば、そのコントローラーのデフォルトのレイアウトを変更したい場合は

class ProductsController < ApplicationController
  layout "inventory"
  #...
end

シンボルで指定すれば、レイアウトを遅延させて決定できる。

class ProductsController < ApplicationController
  layout :products_layout
 
  def show
    @product = Product.find(params[:id])
  end
 
  private
    def products_layout
      @current_user.special? ? "special" : "products"
    end
 
end

メソッドの戻り値に文字列をセットしておいて、あとで評価するということですね。

Procオブジェクトを渡せば、リクエストの内容に応じてレイアウトを指定することもできる。

class ProductsController < ApplicationController
  layout Proc.new { |controller| controller.request.xhr? ? "popup" : "application" }
end

コントローラーインスタンスがリクエスト内容を保持しているようです。

二重レンダリングエラーを避ける(2.2.14)

and returnを使えば、レンダー先を指定したところで処理を終えるのが簡単。

def show
  @book = Book.find(params[:id])
  if @book.special?
    render action: "special_show" and return
  end
  render action: "regular_show"
end

redirect_toを使用する(2.3)

redirect_toメソッドは、別のURLに対して改めてリクエストを再送信するよう、ブラウザに指令を出すためのもの。

redirect_backを使う場合、戻り先の保証はHTTP_REFERERヘッダーによって行われるが、ブラウザが常に保証しているとは限らないので以下のようにして、失敗時どこに飛ぶかの設定は必要。

redirect_back(fallback_location: root_path)

headを使用する(2.4)

headを指定し、bodyなしのレスポンスを返すことが出来る。

head :bad_request

以下のようにヘッダーが生成される。

HTTP/1.1 400 Bad Request
Connection: close
Date: Sun, 24 Jan 2010 12:15:53 GMT
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
X-Runtime: 0.013483
Set-Cookie: _blog_session=...snip...; path=/; HttpOnly
Cache-Control: no-cache

感想

ActiveRecordについてのトピックが終わって、ActionViewに関するトピックに入りました。

ビューに関するトピックはもう１つだけあるのですが、飛ばします！！

というのが、次に作ろうとしてるアプリはRailsAPI+Vue.jsの予定なので、ビューの知識がすぐに活きないからです。

そして、知識としても結構細々してるので、必要に応じて参照すればいいかな、と。

コントローラーはガッツリ使うので、読んでいこうと思います。

要検証

• present?, any?, exists? の違い
• where説を文字列で指定するincludeについて、referencesメソッドを打つか打たないかでのSQL文の違い

Article.includes(:comments).where("comments.visible = true").references(:comments)