[Из песочницы] Что нового в Rails 5.101.05.2017 02:03

Rails 5.1: любимый JavaScript, системные тесты, зашифрованные секреты и многое другое


image

В рамках празднования 12-го RailsConf в Фениксе, штат Аризона на этой неделе, мы с гордостью сообщаем, что Rails 5.1 готов в его окончательной форме! Мы сделали более 4 100 коммитов с релиза Rails 5.0 делая его все ЛЕГЧЕ, ПРОЩЕ, и, ухх, ВЕСЕЛЕЕ? (Это шутка RailsConf).

Катушка подсветки действительно не изменилась с первой беты, но вот повтор:

Любимый JavaScript


На протяжении многих лет у нас были бурные, возможно, даже спорные отношения с JavaScript. Но это время прошло. JavaScript сильно улучшился за последние несколько лет, особенно с появлением ES6, а также с инструментами для компоновки и компиляции, такими как Yarn и webpack. Rails охватывает оба этих решения с распростертыми объятиями и пропускает любой прошлый поток воды под мостом.

JavaScript и Ruby разделяют глубокую философскую связь с языковым дизайном, если не управлением экосистемами. Давайте сосредоточимся на тех аспектах, которые у нас есть, и поможем программистам Rails извлечь все лучшее из JavaScript с помощью некоторых ключевых руководящих принципов.

Улучшения в Rails 5.1 сосредоточены на трех основных частях:

  1. Управлять зависимостями JavaScript от NPM с помощью Yarn. Подумайте о Yarn, как о Bundler для JavaScript (в нее даже вовлечен Yehuda Katz!). Это позволяет легко управлять зависимостями от библиотек, таких как React или что-либо еще от NPM. Все, что вам нужно, через Yarn становится доступным для использования в asset pipeline, как и ресурсов, принадлежащих сторонним субъектам из директории vendor/assets. Просто используйте binstub bin/yarn для добавления зависимостей.
  2. По желанию компилируйте JavaScript с помощью webpack. Несмотря на то, что для JavaScript имеется миллион различных модулей/компиляторов модулей, webpack быстро стал превосходным выбор. Мы упростили использование webpack с Rails с помощью нового гема Webpacker, который вы можете настроить автоматически в новых проектах с помощью --webpack (или даже --webpack=react, --webpack=angular, или --webpack=vue для индивидуальной конфигурации). Это полностью совместимо с asset pipeline, который вы можете продолжать использовать для изображений, шрифтов, звуков и т.п. У вас даже может быть некоторый JavaScript в asset pipeline, и некоторые сделанный через webpack. Это все управляется через Yarn, который включен по умолчанию.
  3. Отбросьте jQuery как зависимость по умолчанию. Раньше мы подключали jQuery, чтобы предоставить такие функции, как data-remote, data-confirm и другие части Rails UJS. Эта зависимость больше не нужна, так как мы переписали rails-ujs для использования ванильного JavaScript. Вы, конечно, по-прежнему можете использовать jQuery, но вам это больше не нужно.

Благодаря Liceth Ovalles за ее работу по интеграции Yarn, Dangyi Liu за работу над rails-ujs и Guillermo Iguaran за сопровождение всего этого!

Системные тесты


В своем выступлении в RailsConf в 2014 году я подробно рассказал о том, как чрезмерное сосредоточение на модульных тестах (и TDD) привело нас в заблуждение. Хотя модульные тесты являются частью полного тестового решения, они не самые важные. Интеграционные тесты, которые проверяют поведение на всем пути от контроллеров через модели и представления, должны играть гораздо большую роль. Rails уже имеет отличный встроенный ответ на это.

Но интеграционные тесты не помогают тестировать всю систему, если эта система использует JavaScript. И большинство основных веб-систем сегодня в какой-то мере полагаются на JavaScript. Вот тут-то и начинаются системные тесты под управлением реального браузера.

Ответы на системные тесты, подобные этому, в Ruby называется Capybara. Это просто было своеобразное приключение, чтобы правильно настроить его в Rails. Так что теперь мы встроили его прямо во фреймворк! Вы получаете прекрасную оболочку Capybara, которая предварительно настроена для Chrome и улучшена, чтобы обеспечить скриншоты сбоев в рамках Action Dispatch. Вам также больше не нужно беспокоиться о дополнительных стратегиях очистки базы данных, потому что встроенные транзакционные тесты теперь откатывают тестовые изменения системы.

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

Спасибо Eileen M. Uchitelle за ее работу, извлеченную из Basecamp!

Зашифрованные секреты


Если вы проверяете производственные пароли, ключи API и другие секреты, скрытые в вашей системе контроля версий, вы поступаете неправильно. Это не безопасно, и вы должны прекратить это! Теперь это просто наставление, но без связного ответа на то, что вы должны делать вместо этого, это также не очень полезно.

Люди уже давно загружают ENV для хранения этих секретов или используют множество других решений. Существуют всевозможные компромиссы и недостатки в модели ENV, не в последнюю очередь в том, что вам все еще нужно хранить эти секреты где-то в другом месте.

Вдохновленные гемом sekrets Ara T. Howard, мы создали управление зашифрованными секретами в Rails 5.1. Вы можете настроить новый файл зашифрованных секретов с помощью секретов bin/rails secrets:setup. Это создаст мастер-ключ, который вы будете хранить вне хранилища, но позволит вам закоммитить ваш актуальный продакшн-секрет в вашу систему контроля версий. Затем они дешифруются в процессе либо через введенный ключевой файл, либо через RAILS_MASTER_KEY в ENV.

Спасибо Kasper Timm Hansen за работу над этим и Ara за вдохновение!

Параметризированный mailer


Action Mailer смоделирован по образцу Action Controller. Он поддерживает основы Abstract Controller, но давно находится в невыгодном положении от своего кузена-контроллера в том, как он может разделять логику между действиями.

В Action Controller обычно используется before_action и подобные обратные вызовы для извлечения логики, применяемой к нескольким действиям. Это выполнимо, поскольку хеш params доступен до вызова этого действия. Но в Action Mailer мы использовали обычные сигнатуры методов с явными аргументами, поэтому эти аргументы не были доступны для фильтров, которые выполнялись перед действиями.

С помощью параметризированного mailer’а мы теперь предоставляем вам возможность вызывать mailer с параметрами, которые, как и в контроллерах, доступны до вызова этого действия. Это сочетается с параметрами по умолчанию for/from/reply_to заголовков, что резко сокращает действия mailer’а.

Он обладает полной обратной совместимостью, и вы можете конвертировать только mailer’ы, которые в выиграют от этого в первую очередь.

Прямые и разрешенные маршруты


У нас есть прекрасный простой API для объявления новых маршрутов ресурсов. Но если вы хотите добавить новые программируемые маршруты, у которых есть логика, определяющая конечный пункт назначения на основе параметров, вам придется разгребать это самостоятельно с помощью хелперов и другими беспорядочными подходами.

С помощью направленных маршрутов вы теперь можете объявлять программные маршруты, которые со всей мощью Ruby будут выполнять разные вещи в зависимости от переданных параметров.

С разрешенными маршрутами вы можете перепрограммировать полиморфный поиск моделей, основанных прямо на совместимых методах. Таким образом, это позволит вам превратить link_to @comment в конечный маршрут, такой как 
message_path(@comment.parent, anchor: "comment_#{@comment.id}").

Спасибо Andrew White за то, что он сделал всю эту работу!

Объединение form_tag/form_for с form_with


У нас уже есть две параллельные структуры для создания форм. Те, которые основывались на записи через form_for, где мы использовали условную конфигурацию для извлечения деталей, и вручную конфигурировали их с помощью form_tag. Теперь мы объединили эти две иерархии с form_with. Одно корневое дерево, которое вы можете настроить с помощью выведенной записи или вручную. Это намного лучше и проще.

Спасибо Kasper Timm Hansen за это тоже!

Все остальное


Помимо основной части, у нас есть сотни других исправлений и улучшений во всем фреймворке. Пожалуйста, прочтите CHANGELOG, чтобы ознакомиться со всеми полезными вещами:
  • Action Cable CHANGELOG
  • Action Mailer CHANGELOG
  • Action Pack CHANGELOG
  • Action View CHANGELOG
  • Active Model CHANGELOG
  • Active Record CHANGELOG
  • Active Support CHANGELOG
  • Active Job CHANGELOG
  • Railties CHANGELOG

У нас есть большая сводка изменений высокого уровня в примечаниях к выпуску.

Вашим менеджером релиза Rails 5.1 был Rafael França.

Согласно нашей политике обслуживания выпуск Rails 5.1 означает, что исправления ошибок будут применяться только к 5.1.x, обычным проблемам безопасности до 5.1.x и 5.0.x, а также к серьезным проблемам безопасности до 5.1.x, 5.0.x и 4.2.х. Это означает, что 4.x и ниже по существу не будут поддерживаться!

Спасибо всем в сообществе за их добросовестную работу по тестированию бета-версии и выпуску кандидатов в Rails 5.1! Мы сделали более 600 коммитов после сообщений об ошибках и проблемах, вызванных этим процессом. Thank you! Gracias! Merci! TAK!

Оригинал статьи

Комментарии (2)

  • 30 апреля 2017 в 20:28

    +5

    ↑

    ↓

    Если вы проверяете производственные пароли, ключи API и другие секреты, скрытые в вашей системе контроля версий, вы поступаете неправильно.

    If you«re checking production passwords, API keys, and other secrets undisguised into your revision control system, you«re doing it wrong.

    Перевод сменил смысл предложения на обратный. Отличный ход!

  • 30 апреля 2017 в 23:16

    0

    ↑

    ↓

    Секреты, как мне кажется, проще подгружать с помощью «rbenv-vars» (я надеюсь, вы уже пользуетесь rbenv) и не переизобретать велосипед.

© Habrahabr.ru