Rails의 작동 방식 및 사용 방법

많은 Rails 애플리케이션은 프레임워크 자체를 포함하여 주목 포인트를 많이 사용합니다.하지만 이제 막 Rails에 입사하게 되면 당혹스러울 수 있습니다.우리는 왜 그것들을 필요로 합니까? 그것들은 어떻게 작동하는지, 우리는 언제 그것들을 사용합니까?몇 달 전에 내가 Rails를 배우기 시작했을 때 걱정은 내가 오랫동안 이해한 화제 중의 하나였다.
레일API documentation도 소용없다.그것은 먼저 독자들이 관심사가 해결하고자 하는 문제에 익숙해졌다고 가정한 다음에 해결 방안을 제공하면 혼란만 증가시킬 뿐이다.
그래서 저는 몇 가지 연구를 했는데 인터넷에 재미있는 관심 지혜가 많이 퍼져 있는 것을 발견했습니다. 예를 들어 DHHthis의 블로그 게시물이 관심의 용법을 보여주거나 핵심 Rails 구성원these이 관심answersA May of WTFs thread과explaining가 관심metaphor of writing하는 것을 발견했습니다.
이 블로그 글은 이러한 흩어진 정보를 정리하여 일관된 화면을 묘사하고 관심사가 어떻게 당신이 더 좋은 코드를 작성하는 데 도움을 줄 수 있는지 보여 주려고 한다.

문제를 해결하다

Using a concern lets you extract the common logic from different classes into a reusable module.

Post와 Comment 두 가지 모드를 고려하십시오.그것들에 특정한 코드를 제외하고 두 모델 모두 그 가시성을 처리하는 코드, 즉 visible_to 속성, is_visible 실례 방법과 count_all_visible 유형을 포함한다.가시성을 비슷한 방식으로 제어해야 하는 다른 모델도 많을 수 있습니다.만약 이 코드를 추상화하는 방법이 있다면 다행이다.

# post.rb

class Post < ApplicationRecord
  belongs_to :author
  has_many :comments, dependent: :delete_all
  has_rich_text :content

  validates :title, presence: true, length: { minimum: 2 }
  validate :has_valid_content

  attr_accessor :visible_to

  def is_visible?
    visible_to.present?
  end

  def has_valid_content
    # some code
  end

  def self.count_all_visible
    all.select { |item| item.is_visible? }
  end
end

# comment.rb

class Comment < ApplicationRecord
  belongs_to :post
  validates :commenter, :body, presence: true

  attr_accessor :visible_to

  def is_visible?
    visible_to.present?
  end

  def self.count_all_visible
    all.select { |item| item.is_visible? }
  end
end

무엇이 걱정입니까?

A lot of concerns are simply Ruby modules that are mixed in, with no additional stuff added. And then for a few cases, like when your concern includes both class and instance methods, or you want to call class methods on mixin, you can use extend ActiveSupport::Concern. - DHH

레일Concern은 확장ActiveSupport::Concern 모듈의 모듈입니다.주목점은 클래스를 포함해서 사용할 수 있도록 방법 (실례와 클래스) 과 상수를 가진 모듈을 하나의 클래스에 포함시킬 수 있도록 합니다.
관심사는 두 개의 모듈을 제공합니다.

included

블록을 포함하는 코드는 클래스를 포함하는 상하문에서 계산한다.예를 들어 Post에 관심사가 포함된 경우 included 블록의 모든 내용은 기록Post처럼 평가됩니다.

클래스 매크로 (검증, 관련, 역할 영역 등) 를 작성할 수 있으며, 어떤 방법이든 클래스를 포함하는 실례적인 방법이 될 수 있습니다.

class_methods

이 블록에 추가하는 방법은 클래스를 포함하는 클래스 방법이 된다.

블록이 아닌 class_methods라는 중첩 모듈을 만들 수 있습니다.

Taggable이라는 질문이 있습니다.

module Taggable
  extend ActiveSupport::Concern

  included do

  end

  class_methods do

  end
end

A concern is a module that you extract to split the implementation of a class or module in coherent chunks, instead of having one big class body. The API surface is the same one, they just help organize the code. A concern is a regular Ruby mixin, there’s nothing else, it is not a new concept. It is plain Ruby. - Xavier Noria

관심사는 어떻게 사용합니까?ClassMethods 관심사Visible와 Post 모델에서 가시성과 관련된 코드를 추출합니다.일반적으로 Comment 관심사는 실체의 가시성과 관련되고 실체의 가시성 여부와 관련된다.

# visible.rb

module Visible
  extend ActiveSupport::Concern

  # The code inside the included block is evaluated
  # in the context of the class that includes the Visible concern.
  # You can write class macros here, and
  # any methods become instance methods of the including class.
  included do
    attr_accessor :visible_to

    def is_visible?
      visible_to.present?
    end
  end

  # The methods added inside the class_methods block (or, ClassMethods module)
  # become the class methods on the including class.
  class_methods do
    def count_all_visible
      all.select { |item| item.is_visible? }
    end
  end
end

이 관심사를 사용하려면 평소와 같이 이 모듈을 포함하십시오.예를 들어 Visible 모델이 Post 기능을 필요로 한다면 visibility 문제를 포함할 것이다.

class Post
  include Visible

end

이 관심사를 포함하여 Visible 속성, visible_to 실례 방법과 is_visible 클래스 방법을 count_all_visible 클래스에 추가합니다.
아래의 테스트는 이 점을 설명했다.

require "test_helper"

class PostTest < ActiveSupport::TestCase

  test "Post can include the visible concern" do
    post = Post.new
    assert_not post.is_visible?

    post.visible_to = "reader"
    assert_equal "reader", post.visible_to
    assert post.is_visible?

    assert_equal [], Post.count_all_visible
  end
end

왜 우리는 걱정해야 합니까?
너는 이렇게 똑똑한 것이 무슨 의의가 있다고 생각할 수 있다.만약 우리가 중심 위치에서 흔히 볼 수 있는 행동을 추상적으로 하려고 한다면, 우리는 간단하게 새로운 종류를 만들어서, 검색을 독립된 대상에 봉인할 수 없습니까?니가 맞았어.
공유 코드를 포함하는 클래스를 만들어서 실례화한 다음 사용할 수 있습니다.

visibility_manager = Visibilty.new

visibility_manager.is_visible(post)

그러나 관심사는 보통 적당한 추상량에 불과해 더욱 우호적인 API를 만들어 낸다.모든 필요한 방법은 주 대상에 있기 때문에 Post와 같은 중간 대상을 도입하여 공유 코드에 접근할 필요가 없다.
다음은 DHH가 이 문제를 어떻게 해결하는지입니다.

So that’s another way of putting this: It’s a writing style. Like using subheads to explain subservient ideas within a broader context. You could probably extract all those subheads out, and turn them into little essays of their own. But that’s often just not the right level of extraction. As you saw, the Accessor role starts life as literally just two methods! It doesn’t warrant being turned into it’s own class. It doesn’t have an independent center of gravity. - A May of WTFs

이것이 바로 우리가 관심을 가지는 것이다. 관련 방법을 한데 묶는 방법이며, 동시에 여전히 같은 종류 아래에서 생활하는 것이다.
이것은 구조화된 창작이다.

Original Post: How Rails Concerns Work and How to Use Them