DEV Community: Sergei Malykh

Custom DI

Sergei Malykh — Mon, 20 Nov 2023 14:09:32 +0000

Экспериментирую с Dependency Injection. Хочется сделать такой код, который помимо основной функции, изоляции зависимостей, также будет хорошо восприниматься IDE (с переходами по коду). Интерфейс видится примерно таким:

class ExternalApi
  def self.call = :api_result
end

class DI < Module
  def included(base)

  end
end

class Receiver1
  include DI.new { def external_api = ExternalApi.call }
end

Receiver1.new.external_api # => :api_result

Метод external_api добавляется как зависимость в инстанс Receiver1. Все работает, как задумано. Чуть-чуть модифицируем код:

class Receiver2
  include DI.new do
    def external_api = ExternalApi.call
  end
end

Receiver2.new.external_api # => NoMethodError: undefined method `external_api' for #<Receiver2:0x00007f06274aa7e8>

В чем проблема? Интуитивно понятно, что где-то нарушается порядок выполенения операторов. Но где именно? Попробуем разобраться. В ruby есть средства для анализа собственного кода. Чтобы понять, как код воспринимается виртуальной машиной, можно воспользоваться модулем RubyVM::AbstractSyntaxTree:

RubyVM::AbstractSyntaxTree.parse(<<~RUBY)
  include DI.new { def external_api = :api_result }
RUBY

На выходе получим синтаксическое дерево:

=> (SCOPE@1:0-1:49
 tbl: []
 args: nil
 body:
   (FCALL@1:0-1:49 :include
      (LIST@1:8-1:49
         (ITER@1:8-1:49 (CALL@1:8-1:14 (CONST@1:8-1:10 :DI) :new nil)
            (SCOPE@1:15-1:49
             tbl: []
             args: nil
             body:
               (DEFN@1:17-1:47
                mid: :external_api
                body: (SCOPE@1:17-1:47 tbl: [] args: (ARGS@1:17-1:33 pre_num: 0 pre_init: nil opt: nil first_post: nil post_num: 0 post_init: nil rest: nil kw: nil kwrest: nil block: nil) body: (LIT@1:36-1:47 :api_result))))) nil)))

Многовато текста. Изолируем код, уберем излишнюю реализацию:

RubyVM::AbstractSyntaxTree.parse(<<~RUBY)
  include Class.new(Module) { 1 }
RUBY

Отформатировано и обрезано для лучшего восприятия:

FCALL@1:0-1:29 :include
  (
    LIST@1:8-1:29
      (
        ITER@1:8-1:29
          (CALL@1:8-1:25 (CONST@1:8-1:13 :Class) :new (LIST@1:18-1:24 (CONST@1:18-1:24 :Module) nil))
          (SCOPE@1:26-1:29 tbl: [] args: nil body: (LIT@1:27-1:28 1))
      )
      nil
  )

Метод include принимает список аргументов LIST. Единственным переданным аргументом является элемент ITER. Его предназначение сокрыто где-то в исходниках ruby, но очевидно, что он объединяет вызов метода (Class.new в данном случае) с переданным в него блоком кода SCOPE. В итоге, сначала инициализируется класс с блоком, затем результат передается в include.

Сравним с реализацией Receiver2:

RubyVM::AbstractSyntaxTree.parse(<<~RUBY)
  include Class.new(Module) do
    1
  end
RUBY

ITER@1:0-3:3
  (
    FCALL@1:0-1:25 :include
      (
        LIST@1:8-1:25
          (
            CALL@1:8-1:25 (CONST@1:8-1:13 :Class) :new (LIST@1:18-1:24 (CONST@1:18-1:24 :Module) nil)
          )
          nil
      )
  )
  (
    SCOPE@1:26-3:3 tbl: [] args: nil body: (LIT@2:2-2:3 1)
  )

В этом случае блок SCOPE ассоциирован непосредственно с include. То есть, класс инициализируется без блока, который вместо этого идет как аргумент в include.

Как всегда после дебага, можно заглянуть в документацию, и найти там подтверждения разного приоритета операторов блока:

{ ... } blocks have priority below all listed operations, but do ... end blocks have lower priority.

Возвращаясь к начальной задаче, код можно было бы переписать, используя скобки. Но это не красивое и хрупкое решение, продолжаю поиски =)

class Receiver2
  include(
    DI.new do
      def external_api = ExternalApi.call
    end
  )
end

Receiver2.new.external_api # :api_result

Нюансы использования rails-консоли

Sergei Malykh — Mon, 04 Sep 2023 13:12:00 +0000

Все мы постоянно пользуемся rails-консолью. Она незаменима при отладке в development. Но и в боевом окружении временами тоже что-то требуется посмотреть. Недавно наткнулся на один неочевидный нюанс, который заставил поразбираться.

Есть некий код, который использует ActiveRecord::Associations::Preloader для кастомной подгрузки ассоциации (выборочный select). Отлаживаю его в консоли:

products_scope = Product.select(:id, :name)
ActiveRecord::Associations::Preloader.new(records: line_items, associations: :product, scope: products_scope).call

На проде можно предварительно для удобства перенаправить в консоль SQL-запросы:

ActiveRecord::Base.logger = Logger.new(STDOUT)

Что мы видим, когда запускаем этот код?

DEBUG -- :   Product Load (3.8ms)  SELECT "products"."id", "products"."name" FROM "products" WHERE "products"."id" = $1  [["id", 1092717]]
DEBUG -- :   Product Load (1326.4ms)  SELECT "products"."id", "products"."name" FROM "products"

Товары подгружаются дважды. Первый раз, как и ожидается с фильтрацией по id товара. А вот второго быть вообще не должно, к тому же запускается full scan таблицы. И это production-окружении!. Получается AR-preloader не работает? почему так происходит?

Покопался в исходниках и понял, что прелоадер все-таки ни при чем. Проблема возникает при отображении результата выполнения команды в консоли. При этом под капотом дергается некий метод, который форматирует вывод. Какой именно, не понятно. Теоретически, это может быть метод этого самого результата, либо другого объекта с аргументом в виде результата. Попробуем выяснить, как именно.

Вызываемые методы могут быть залогированы при помощи модуля TracePoint. Он позволяет отлавливать разные типы событий, в том числе события call, вызываемые на объекте типа Method. То есть, таким образом мы можем залогировать вызовы любых методов.

result = ActiveRecord::Associations::Preloader.new(records: line_items, associations: :product, scope: products_scope).call; 1
calls = []
trace = TracePoint.new(:call, :c_call) do |tp|
  if tp.binding.eval('self') == result || tp.parameters.any? { tp.binding.eval(_1.last) == result rescue false }
    calls << "#{tp.defined_class}##{tp.method_id} got called (#{tp.path}:#{tp.lineno})"
  end
end
trace.enable
result

Результат, вывод которого хотим залогировать, присваиваем переменной, и гасим вывод команды присваивания. Далее отлавливаем вызовы методов, в которых либо аргументом является result либо принадлежащие самому result. Включаем логирование, инициируем вывод результата в консоль.

Далее нужно отключить логирование и посмотреть, что накопилось в calls:

trace.disable
calls
=> ["Array#pretty_print got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:366)"]

Уже теплее, result содержит массив и для вывода в консоль используется один из методов модуля PP. Очевидно, что для отображения на каждом элементе массива вызывается еще какой-то метод. Изменим немного код:

result = ActiveRecord::Associations::Preloader.new(records: line_items, associations: :product, scope: products_scope).call[0]; 1
trace.enable
result
...
trace.disable
calls
=> ["PP::ObjectMixin#pretty_print got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:317)",
    "Module#instance_method got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:318)",
    "UnboundMethod#bind_call got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:320)",
    "Kernel#method got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:320)",
    "Method#owner got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:323)",
    "BasicObject#!= got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:323)",
    "Module#== got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:323)",
    "BasicObject#! got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:325)",
    "PP::ObjectMixin#pretty_print_instance_variables got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:345)",
    "Kernel#instance_variables got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:346)",
    "Array#sort got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:346)",
    "Symbol#<=> got called (~/.rbenv/versions/3.1.2/lib/ruby/3.1.0/pp.rb:346)"]

Немного покопавшись в исходниках PP, не сложно найти, что для вывода объекта все его instance-переменные выбираются и отображаются при помощи pp:

pp(obj.instance_eval(v))

Объект ActiveRecord::Associations::Preloader содержит instance-переменную @preload_scope, в которой сохранен products_scope. При отображении с помощью pp происходит выполенение запроса к базе, что и приводит к этой неочевидной ситуации.

pp Product.select(:id, :name)
D, [2023-09-04T15:55:01.574901 #28800] DEBUG -- :   Product Load (1185.7ms)  SELECT "products"."id", "products"."name" FROM "products"

Валидация кастомных типов данных для dry-schema

Sergei Malykh — Fri, 09 Jun 2023 08:52:30 +0000

При задании схемы есть возможность указать кастомный тип данных на основе конструктора одного из базовых типов. Для примера возьмем конвертер римских чисел в Integer. При вводе невалидной комбинации должна возращаться человеко-читаемая ошибка.

RomanNumber =
  Dry.Types::Integer.constructor do |input|
    roman_to_int(input)
  end

schema =
  Dry::Schema.Params do
    optional(:int).maybe(:integer)
    optional(:roman).maybe(RomanNumber)
  end

Реализация функции roman_to_int не важна. Возьмем, например, такую:

H = {"VI"=>4, "XI"=>9, "LX"=>40, "CX"=>90, "DC"=>400, "MC"=>900, "I"=>1, "V"=>5, "X"=>10, "L"=>50, "C"=>100, "D"=>500, "M"=>1000}.transform_values { " #{_1}" }
def roman_to_int(roman_string)
  roman_string.reverse.gsub(Regexp.union(H.keys), H).split.sum(&:to_i)
end

Проверим, что будет получаться при валидации схемы:

schema.call(int: 'invalid')
# => #<Dry::Schema::Result{:int=>"invalid"} errors={:int=>["must be an integer"]} path=[]>

schema.call(roman: 'invalid')
# => #<Dry::Schema::Result{:roman=>0} errors={} path=[]>

Первый результат ожидаем и нагляден, а вот второй - просто не корректен. Вместо ошибки о невалидности мы получили 0. Нужно добавить проверку римской нотации. Например, такую:

RomanNumber =
  Dry.Types::Integer.constructor do |input|
    if roman_valid?(input)
      roman_to_int(input)
    end
  end

INVALID_ROMAN = /[MDCLXVI]/i
def roman_valid?(s)
  !s.match?(INVALID_ROMAN)
end

Возникает вопрос, а что делать, если нотация не валидна? Никаких подсказок в документации нет, попробуем вызвать exception:

RomanNumber =
  Dry.Types::Integer.constructor do |input|
    if roman_valid?(input)
      roman_to_int(input)
    else
      raise 'invalid roman number'
    end
  end

Метод тыка не сработал, в результате вызова получаем RuntimeError, а не красивую ошибку:

schema.call(roman: 'invalid')
# RuntimeError: invalid roman number

Придется покопаться в исходниках... Библиотека dry-types специальным образом обрабатывает 3 класса ошибок: NoMethodError, TypeError, ArgumentError. Поэтому, чтобы увидеть желаемую ошибку валидации, нужно использовать один из перечисленных:

RomanNumber =
  Dry.Types::Integer.constructor do |input|
    if roman_valid?(input)
      roman_to_int(input)
    else
      raise TypeError, 'invalid roman number'
    end
  end

schema.call(roman: 'invalid')
# => #<Dry::Schema::Result{:roman=>"invalid"} errors={:roman=>["must be an integer"]} path=[]>

Вот теперь результат нам подходит.

Стоит отметить, что решение с перехватом ошибок конструктора не однозначно. NoMethodError довольно частая ошибка в коде. Все наверняка встречали ситуацию, когда вместо ожидаемого значения, в переменной оказывается nil. В этом случае вызов большинства методов вызовет ту самую NoMethodError:

roman_to_int(nil)
# => NoMethodError: undefined method `reverse' for nil:NilClass

Ошибка может возникнуть как вследствие невалидных данных, так и вследствие ошибок в самом коде. Следует об этом помнить, когда пишете кастомный конструктор.

Итоговый код:

H = {"VI"=>4, "XI"=>9, "LX"=>40, "CX"=>90, "DC"=>400, "MC"=>900, "I"=>1, "V"=>5, "X"=>10, "L"=>50, "C"=>100, "D"=>500, "M"=>1000}.transform_values { " #{_1}" }
def roman_to_int(roman_string)
  roman_string.reverse.gsub(Regexp.union(H.keys), H).split.sum(&:to_i)
end

INVALID_ROMAN = /[MDCLXVI]/i
def roman_valid?(s)
  !s.match?(INVALID_ROMAN)
end

RomanNumber =
  Dry.Types::Integer.constructor do |input|
    if roman_valid?(input)
      roman_to_int(input)
    else
      raise TypeError, 'invalid roman number'
    end
  end

schema =
  Dry::Schema.Params do
    optional(:int).maybe(:integer)
    optional(:roman).maybe(RomanNumber)
  end

schema.call(roman: 'invalid')

Валидация даты в dry_schema

Sergei Malykh — Thu, 18 May 2023 08:19:22 +0000

В своих проектах мы активно используем форм-объекты из библиотеки active_dry_form, которая основана на dry_schema. Предположим, что у нас есть форма с выбором даты:

class ArticleForm < ApplicationForm
  fields do
    params do
      required(:published_on).filled(:date)
    end
  end
end

В форме указывается дата публикации. Примем, что это должна быть дата в будущем. Первая мысль - использовать для валидации синтаксис предикатов:

required(:published_on).filled(:date, gt?: Time.zone.today)

Тут мы можем попасть на частую ошибку неопытных разработчиков. Указанная таким образом дата закешируется при старте приложения. Немного покопавшись в документации, можно прийти к такому варианту:

required(:published_on).filled(:date) { gt?(Time.zone.today) }

На первый взгляд, это именно то, что надо. Вызов даты использован внутри блока, при каждом выполнении предиката должно подставляться актуальное значение. К сожалению, это не так. Предикат кешируется вместе с переданным значением.

Последний вариант выглядит наглядно, попробуем реализовать нечто подобное, расширив функционал dry. Формы в active_dry_form наследуют контракты общего ApplicationContract:

require 'dry/validation/extensions/predicates_as_macros'

class ApplicationContract < ActiveDryForm::BaseContract
  PREDICATES = Dry::Validation::PredicateRegistry.new

  register_macro(:predicate?) do |macro:|
    next unless value # optional

    capture = Dry::Schema::Macros::Value.new.instance_exec(&macro.args[0])
    predicate_args = [*capture.args, value]
    message_opts = PREDICATES.message_opts(capture.name, predicate_args)
    key.failure(capture.name, message_opts) unless PREDICATES.call(capture.name, predicate_args)
  end

Созданный макрос используется так:

class ArticleForm < ApplicationForm
  fields do
    params do
      required(:published_on).filled(:date)
    end

    rule(:published_on).validate(predicate?: -> { gt?(Time.zone.today) })
  end
end

В составе dry_validation есть расширение predicates_as_macros. Само по себе оно нам не интересно, но в нем задан класс PredicateRegistry, который можно использовать для выполнения предиката и генерации сообщений об ошибках. Переданный блок с валидацией даты можно найти в аргументах макроса macro.args[0]. Код в блоке подразумевает использование нужного контекста для предиката, создадим его Dry::Schema::Macros::Value.new и скомпилируем предикат instance_exec(&macro.args[0]). Получив предикат, выполняем его PREDICATES.call(capture.name, ...) и возвращаем ошибку, если неудачно.

PS:
У предложенного метода есть небольшой недостаток. Таким образом не получится использовать алгебру предикатов, указав, например, одновременно верхнюю и нижнуюю границу дат:

rule(:published_on).validate(predicate?: -> { gt?(Time.zone.today) & lt?(Time.zone.today + 1.month) })

Комбинированное условие имеет класс Dry::Logic::Operations::And, не удалось с наскока решить эту проблему. Возможно у кого-то есть еще идеи?