2015-12-27 3 views
2

В следующем коде Rails,Зачем использовать метод tap здесь?

root.join('lib', 'assets', 'bower_components').to_s.tap do |bower_path| 
    config.sass.load_paths << bower_path 
    config.assets.paths << bower_path 
end 

Я задаюсь вопросом, почему мы должны использовать кран здесь

почему бы не просто использовать

bower_path = root.join('lib', 'assets', 'bower_components').to_s 
config.sass.load_paths << bower_path 
config.assets.paths << bower_path 

чем выгода использования крана?

+0

Это вопрос предпочтения. – sawa

+0

Возможный дубликат [преимущество метода крана в рубине] (http://stackoverflow.com/questions/17493080/advantage-of-tap-method-in-ruby) –

ответ

6

Одним из преимуществ может быть то, что tap возвращает объект, на который он был вызван. Ваши второй версии не совсем то же самое, что и версия tap. Он идентичен:

bower_path = root.join('lib', 'assets', 'bower_components').to_s 
config.sass.load_paths << bower_path 
config.assets.paths << bower_path 
bower_path 

Это зависит от контекста, требуется ли эта функция или нет.

1

В вашем случае я не вижу никакой пользы.

Inside tap:

VALUE 
rb_obj_tap(VALUE obj) 
{ 
    rb_yield(obj); 
    return obj; 
} 

Может быть полезно:

  • группировки побочных эффектов вместе
  • функции
  • цепи/трубы
  • уменьшить использование промежуточных переменных
  • легче работать с вложенными хешами

Подводя итог, более «функциональный» стиль

Смежные вопросы