ventaja del método tap en ruby

Estaba leyendo un artículo de blog y noté que el autor usó tapen un fragmento algo como:

user = User.new.tap do |u|
  u.username = "foobar"
  u.save!
end

Mi pregunta es ¿cuál es exactamente el beneficio o la ventaja de usar tap? ¿No podría simplemente hacer:

user = User.new
user.username = "foobar"
user.save!

o mejor aún:

user = User.create! username: "foobar"

Cuando los lectores encuentran:

user = User.new
user.username = "foobar"
user.save!

tendrían que seguir las tres líneas y luego reconocer que solo está creando una instancia nombrada user.

Si fuera:

user = User.new.tap do |u|
  u.username = "foobar"
  u.save!
end

entonces eso quedaría inmediatamente claro. Un lector no tendría que leer lo que hay dentro del bloque para saber que userse crea una instancia .

Otro caso para usar tap es realizar manipulación en el objeto antes de devolverlo.

Entonces en lugar de esto:

def some_method
  ...
  some_object.serialize
  some_object
end

podemos ahorrar línea extra:

def some_method
  ...
  some_object.tap{ |o| o.serialize }
end

En alguna situación, esta técnica puede ahorrar más de una línea y hacer que el código sea más compacto.

Usar tap, como hizo el bloguero, es simplemente un método conveniente. Puede haber sido exagerado en su ejemplo, pero en los casos en los que quisiera hacer un montón de cosas con el usuario, podría decirse que el toque puede proporcionar una interfaz de aspecto más limpio. Entonces, tal vez sea mejor en un ejemplo como sigue:

user = User.new.tap do |u|
  u.build_profile
  u.process_credit_card
  u.ship_out_item
  u.send_email_confirmation
  u.blahblahyougetmypoint
end

El uso de lo anterior facilita ver rápidamente que todos esos métodos están agrupados en el sentido de que todos se refieren al mismo objeto (el usuario en este ejemplo). La alternativa sería:

user = User.new
user.build_profile
user.process_credit_card
user.ship_out_item
user.send_email_confirmation
user.blahblahyougetmypoint

Nuevamente, esto es discutible, pero se puede argumentar que la segunda versión parece un poco más desordenada y requiere un poco más de análisis humano para ver que todos los métodos se invocan en el mismo objeto.

Esto puede resultar útil para depurar una serie de ActiveRecordámbitos encadenados.

User
  .active                      .tap { |users| puts "Users so far: #{users.size}" } 
  .non_admin                   .tap { |users| puts "Users so far: #{users.size}" }
  .at_least_years_old(25)      .tap { |users| puts "Users so far: #{users.size}" }
  .residing_in('USA')

Esto hace que sea muy fácil depurar en cualquier punto de la cadena sin tener que almacenar nada en una variable local ni requerir mucha alteración del código original.

Y, por último, utilícelo como una forma rápida y discreta de depurar sin interrumpir la ejecución normal del código :

def rockwell_retro_encabulate
  provide_inverse_reactive_current
  synchronize_cardinal_graham_meters
  @result.tap(&method(:puts))
  # Will debug `@result` just before returning it.
end

Visualiza tu ejemplo dentro de una función

def make_user(name)
  user = User.new
  user.username = name
  user.save!
end

Existe un gran riesgo de mantenimiento con ese enfoque, básicamente el valor de retorno implícito .

En ese código, depende de save!devolver el usuario guardado. Pero si usa un pato diferente (o el actual evoluciona), es posible que obtenga otras cosas como un informe de estado de finalización. Por lo tanto, los cambios en el pato podrían romper el código, algo que no sucedería si se asegura el valor de retorno con un simpleuser toque o toque.

He visto accidentes como este con bastante frecuencia, especialmente con funciones en las que el valor de retorno normalmente no se usa, excepto en una esquina oscura con errores.

El valor de retorno implícito tiende a ser una de esas cosas en las que los novatos tienden a romper cosas agregando código nuevo después de la última línea sin notar el efecto. No ven lo que realmente significa el código anterior:

def make_user(name)
  user = User.new
  user.username = name
  return user.save!       # notice something different now?
end

Si desea devolver el usuario después de configurar el nombre de usuario, debe hacerlo

user = User.new
user.username = 'foobar'
user

Con taptu podrías salvar ese incómodo regreso

User.new.tap do |user|
  user.username = 'foobar'
end

Da como resultado un código menos desordenado, ya que el alcance de la variable se limita solo a la parte donde realmente se necesita. Además, la sangría dentro del bloque hace que el código sea más legible al mantener el código relevante junto.

Descripción de tapdice :

Se entrega al bloque y luego regresa. El propósito principal de este método es "aprovechar" una cadena de métodos, con el fin de realizar operaciones en resultados intermedios dentro de la cadena.

Si buscamos el código fuente de rails para su tapuso , podemos encontrar algunos usos interesantes. A continuación se muestran algunos elementos (lista no exhaustiva) que nos darán algunas ideas sobre cómo usarlos:

1. Agregar un elemento a una matriz en función de ciertas condiciones

   %w(
   annotations
   ...
   routes
   tmp
   ).tap { |arr|
     arr << 'statistics' if Rake.application.current_scope.empty?
   }.each do |task|
     ...
   end

2. Inicializar una matriz y devolverla

   [].tap do |msg|
     msg << "EXPLAIN for: #{sql}"
     ...
     msg << connection.explain(sql, bind)
   end.join("\n")

3. Como azúcar sintáctico para hacer el código más legible: se puede decir, en el siguiente ejemplo, el uso de variables hashy serveraclara la intención del código.

   def select(*args, &block)
       dup.tap { |hash| hash.select!(*args, &block) }
   end

4. Inicializar / invocar métodos en objetos recién creados.

   Rails::Server.new.tap do |server|
      require APP_PATH
      Dir.chdir(Rails.application.root)
      server.start
   end

   A continuación se muestra un ejemplo del archivo de prueba

   @pirate = Pirate.new.tap do |pirate|
     pirate.catchphrase = "Don't call me!"
     pirate.birds_attributes = [{:name => 'Bird1'},{:name => 'Bird2'}]
     pirate.save!
   end

5. Actuar sobre el resultado de una yieldllamada sin tener que utilizar una variable temporal.

   yield.tap do |rendered_partial|
     collection_cache.write(key, rendered_partial, cache_options)
   end

Una variación de la respuesta de @ sawa:

Como ya se señaló, el uso tapayuda a descubrir la intención de su código (aunque no necesariamente lo hace más compacto).

Las siguientes dos funciones son igualmente largas, pero en la primera tienes que leer hasta el final para descubrir por qué inicialicé un Hash vacío al principio.

def tapping1
  # setting up a hash
  h = {}
  # working on it
  h[:one] = 1
  h[:two] = 2
  # returning the hash
  h
end

Aquí, por otro lado, sabe desde el principio que el hash que se inicializa será la salida del bloque (y, en este caso, el valor de retorno de la función).

def tapping2
  # a hash will be returned at the end of this block;
  # all work will occur inside
  Hash.new.tap do |h|
    h[:one] = 1
    h[:two] = 2
  end
end

Es un ayudante para el encadenamiento de llamadas. Pasa su objeto al bloque dado y, una vez finalizado el bloque, devuelve el objeto:

an_object.tap do |o|
  # do stuff with an_object, which is in o #
end  ===> an_object

El beneficio es que tap siempre devuelve el objeto al que se llama, incluso si el bloque devuelve algún otro resultado. Por lo tanto, puede insertar un bloque de derivación en el medio de una tubería de método existente sin interrumpir el flujo.

Yo diría que usar tap. El único beneficio potencial, como señala @sawa es, y cito: "Un lector no tendría que leer lo que hay dentro del bloque para saber que se crea un usuario de instancia". Sin embargo, en ese punto se puede argumentar que si está utilizando una lógica de creación de registros no simplista, su intención se comunicaría mejor extrayendo esa lógica en su propio método.

Sostengo la opinión de que tapes una carga innecesaria para la legibilidad del código, y podría prescindirse o sustituirse por una técnica mejor, como el método de extracción .

Si bien tapes un método de conveniencia, también es una preferencia personal. Pruébalo tap. Luego escriba un código sin usar el tap, vea si le gusta una forma sobre otra.

Podría haber varios usos y lugares donde podríamos usar tap. Hasta ahora solo he encontrado los siguientes 2 usos de tap.

1) El propósito principal de este método es aprovechar una cadena de métodos para realizar operaciones sobre resultados intermedios dentro de la cadena. es decir

(1..10).tap { |x| puts "original: #{x.inspect}" }.to_a.
    tap    { |x| puts "array: #{x.inspect}" }.
    select { |x| x%2 == 0 }.
    tap    { |x| puts "evens: #{x.inspect}" }.
    map    { |x| x*x }.
    tap    { |x| puts "squares: #{x.inspect}" }

2) ¿Alguna vez se encontró llamando a un método en algún objeto y el valor de retorno no era el que deseaba? Tal vez quisiera agregar un valor arbitrario a un conjunto de parámetros almacenados en un hash. Lo actualizas con Hash. [] , Pero obtienes back bar en lugar del hash params, por lo que debes devolverlo explícitamente. es decir

def update_params(params)
  params[:foo] = 'bar'
  params
end

Para superar esta situación aquí, tapentra en juego el método. Simplemente instálelo en el objeto, luego toque un bloque con el código que desea ejecutar. El objeto se cederá al bloque y luego se devolverá. es decir

def update_params(params)
  params.tap {|p| p[:foo] = 'bar' }
end

Hay docenas de otros casos de uso, intente encontrarlos usted mismo :)

Fuente:
1) API Dock Object Tap
2) Five-Ruby-methods-you-should-be-using

Tienes razón: el uso de tapen tu ejemplo es un poco inútil y probablemente menos limpio que tus alternativas.

Como señala Rebitzele, tapes solo un método de conveniencia, que a menudo se usa para crear una referencia más corta al objeto actual.

Un buen caso de uso tapes para la depuración: puede modificar el objeto, imprimir el estado actual y luego continuar modificando el objeto en el mismo bloque. Vea aquí por ejemplo: http://moonbase.rydia.net/mental/blog/programming/eavesdropping-on-expressions .

De vez en cuando me gusta usar tapmétodos internos para regresar condicionalmente temprano mientras devuelvo el objeto actual de lo contrario.

Existe una herramienta llamada flog que mide qué tan difícil es leer un método. "Cuanto mayor sea la puntuación, más doloroso será el código".

def with_tap
  user = User.new.tap do |u|
    u.username = "foobar"
    u.save!
  end
end

def without_tap
  user = User.new
  user.username = "foobar"
  user.save!
end

def using_create
  user = User.create! username: "foobar"
end

y según el resultado de flog, el método con el que tapes más difícil de leer (y estoy de acuerdo con él)

 4.5: main#with_tap                    temp.rb:1-4
 2.4:   assignment
 1.3:   save!
 1.3:   new
 1.1:   branch
 1.1:   tap

 3.1: main#without_tap                 temp.rb:8-11
 2.2:   assignment
 1.1:   new
 1.1:   save!

 1.6: main#using_create                temp.rb:14-16
 1.1:   assignment
 1.1:   create!

Puede hacer que sus códigos sean más modulares usando tap y puede lograr una mejor gestión de las variables locales. Por ejemplo, en el siguiente código, no es necesario asignar una variable local al objeto recién creado, en el alcance del método. Tenga en cuenta que la variable de bloque, u , tiene un alcance dentro del bloque. En realidad, es una de las bellezas del código ruby.

def a_method
  ...
  name = "foobar"
  ...
  return User.new.tap do |u|
    u.username = name
    u.save!
  end
end

En rieles podemos usar tappara incluir parámetros en la lista blanca explícitamente:

def client_params
    params.require(:client).permit(:name).tap do |whitelist|
        whitelist[:name] = params[:client][:name]
    end
end

Daré otro ejemplo que he utilizado. Tengo un método user_params que devuelve los parámetros necesarios para guardar para el usuario (este es un proyecto de Rails)

def user_params
  params.require(:user).permit(
    :first_name,
    :last_name,
    :email,
    :address_attributes
  )
end

Puede ver que no devuelvo nada, pero ruby ​​devuelve el resultado de la última línea.

Luego, después de algún tiempo, necesitaba agregar un nuevo atributo condicionalmente. Entonces, lo cambié a algo como esto:

def user_params 
  u_params = params.require(:user).permit(
    :first_name, 
    :last_name, 
    :email,
    :address_attributes
  )
  u_params[:time_zone] = address_timezone if u_params[:address_attributes]
  u_params
end

Aquí podemos usar tap para eliminar la variable local y eliminar el retorno:

def user_params 
  params.require(:user).permit(
    :first_name, 
    :last_name, 
    :email,
    :address_attributes
  ).tap do |u_params|
    u_params[:time_zone] = address_timezone if u_params[:address_attributes]
  end
end

En el mundo donde el patrón de programación funcional se está convirtiendo en una mejor práctica ( https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming ), puede ver tap, como un mapvalor único, de hecho , para modificar sus datos en una cadena de transformación.

transformed_array = array.map(&:first_transformation).map(&:second_transformation)

transformed_value = item.tap(&:first_transformation).tap(&:second_transformation)

No es necesario declarar itemvarias veces aquí.

¿Cuál es la diferencia?

La diferencia en términos de legibilidad del código es puramente estilística.

Recorrido por el código:

user = User.new.tap do |u|
  u.username = "foobar"
  u.save!
end

Puntos clave:

• ¿Observa cómo la uvariable ahora se usa como parámetro de bloque?
• Una vez realizado el bloqueo, la uservariable ahora debería apuntar a un Usuario (con un nombre de usuario: 'foobar', y que también está guardado).
• Es agradable y más fácil de leer.

Documentación de API

Aquí hay una versión fácil de leer del código fuente:

class Object
  def tap
    yield self
    self
  end
end

Para obtener más información, consulte estos enlaces:

https://apidock.com/ruby/Object/tap

http://ruby-doc.org/core-2.2.3/Object.html#method-i-tap