dev/mom0tomo

技術メモ

Decorator　Helper　違い

Ruby on Rails

Helperに書かれたメソッドをDecoratorに切り出そうとして、「引数どうするんだっけ」と思った。

Helperだけ、Decoratorだけ0-1で書くときはそれほど迷わないことでも、リファクタリングなど2つ同時に作業するとき意外と迷う。

改めてまとめてみた。

読んだもの

tech.misoca.jp qiita.com izumin.hateblo.jp

学んだこと

Helperとは

  • ViewをよりシンプルにDRYに書くためのモジュール

    • View以外もhelpできるが、基本的にはViewをhelpする（ViewHelperと言ったりする）

    • rails g controllerを実施した際に作成される

Helperの例

module MembersHelper
  # 会員のフルネームを取得する
  def member_full_name(member)
    member.first_name + ' ' + member.last_name
  end
end

Decoratorとは

  • Viewと対応するModelごとに作れる

    • モデルの属性にアクセスする際に変数を介する必要がない

  • Controllerで宣言されたインスタンス変数すべてにdecorateメソッドを適用する

Decoratorの例

moduleMemberDecorator
  # 会員のフルネームを取得する
  def full_name
    first_name + ' ' + last_name
  end
end

Ruby / Railsで日付と日付の差分を求める

Ruby Ruby on Rails

読んだもの

www.rubylife.jp

学んだこと

Timeクラスか、Dateクラスを使う。 時間まで使いたい場合はTimeクラス、日付だけ使いたい場合はDateクラスを使う。

2つのクラスのオブジェクトに対し、「-」を使って差を取得する（引き算ぽい）。

やりたかったこと

期限日と今日の差分を求めて、期限まであと何日か求めたい。

require 'date'

today = Date.current
dead_line = Date.new(2018, 7 ,6)

remain = (dead_line - today).to_i
# -> 3

Date.currentはTime.zoneを、Date.todayはTime.nowを参照している。

また、素のRubyならTimeクラスを使い、 RailsならTimeWithZoneクラスを使うのがいいみたい。

伊藤さんの記事に詳しく書いてあった。

RubyとRailsにおけるTime, Date, DateTime, TimeWithZoneの違い

なぜRailsのpartialではインスタンス変数を参照しない方がいいのか

Ruby on Rails

読んだもの

kadoppe.com

学んだこと

なぜpartialではインスタンス変数を参照しない方がいいのか？

  • コントローラで何を用意すべきか明らかでなくなるから
  • インスタンス変数を介して、partialは呼び出し元のテンプレートだけでなくコントローラとも結びついてしまうので、再利用性が低くなるから

partialにインスタンス変数を使ってしまったところ、直すときcontrollerとの関連がわからなくなり、どこを削除していいのかわからなくなり、自分が書いたコードなのにハマった。

『Ruby on Rails5 アプリケーションプログラミング』　読んだメモ

Ruby on Rails

  • クエリメソッドはその場でDBにアクセスしない（遅延ロード）

    • メソッドチェーン（連鎖して呼び出す）が可能

  • 生成されたクエリはPumaのコンソールに吐き出される

  • whereメソッドを使うと、プレイスホルダー（任意のパラメータを引き渡せる）が使える

    • 動きはfind_byと同じ

  • パラメータ数が少ない時は名前なしにする (params[:publish]))

    • 多い時は名前付きにする (publish: params[:publish])

Active Decoratorメモ

Ruby on Rails

読んだもの

qiita.com GitHub - amatsuda/active_decorator: ORM agnostic truly Object-Oriented view helper for Rails 3, 4 and 5

学んだこと

  • テストのとき、ちょっと変わった書き方をする。
    • →ActiveDecorator::Decorator.instance.decorate(model_instance)を呼び出す

モデルの例

module OrganizationDecorator
  def full_name
    "#{first_name} #{last_name}"
  end
end

テストの例

describe '#full_name' do
  it 'returns the full organization name' do
    organization = Organization.new(first_name: 'John', last_name: 'Doe')
    decorated_organization = ActiveDecorator::Decorator.instance.decorate(organization)

    expect(decorated_organization.full_name).to eq('John Doe')
  end
end

ADの機能は、Rails組み込みのものだと勘違いしていた。

「使えるRSpec入門・その1 」読んだメモ

Ruby on Rails

読んだもの

qiita.com

学んだこと

  • 原則として「1つの example につき1つのエクスペクテーション」で書く

    • テストの保守性が良くなるため

  • letで宣言できる変数

**インスタンス変数の例**
let(:user) { User.new(params) }

# 同じ意味
user = User.new(params)

ローカル変数の例

let(:params) { { name: 'たろう' } }

# 同じ意味
@params = { name: 'たろう' }

  • let は遅延評価される

    • before + インスタンス変数は遅延評価されない
    • 必要になる瞬間まで呼び出されないので効率がよい

  • it do ... endのことをexampleと呼ぶ

  • subject { user.greet } を宣言するときの決まり

    • expect(user.greet).to eq 'hogehoge'が
    • is_expected.to eq 'hodehode'という書き方になる

  • shared_examples 'foo' do ... end で再利用したいexampleを定義して、 it_behaves_like 'foo' で定義したexampleを呼び出せる

  • let の遅延評価によってテストが失敗する場合は、かわりに let! を使う

  • テストコードは「DRYさ」よりも「読みやすさ」を大事にする