Что нового в Rails 5.1

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, чтобы ознакомиться со всеми полезными вещами:


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

Вашим менеджером релиза 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!

Оригинал статьи
  • +17
  • 9,8k
  • 9
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 9
  • +12
    Если вы проверяете производственные пароли, ключи API и другие секреты, скрытые в вашей системе контроля версий, вы поступаете неправильно.

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

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

      Забавно то, что это 1 в 1 перевод из google translate, буква в букву)

      • +2

        Здесь, вероятно, "check into" используется в значении, противоположном к "check out". К проверкам это вообще не имеет никакого отношения, так что перевод тупо машинный, без понимания написанного.

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

        "Несмотря на то, что для JavaScript имеется миллион различных модулей/компиляторов модулей, webpack быстро стал превосходным выбор". Машинный перевод?

        • +2
          Давно думал о том, чтобы отключить jquery и вместо coffee начать использовать es6. И вот оно! Буду обновляться!
          • 0
            Управлять зависимостями JavaScript от NPM с помощью Yarn

            bower уже не торт?
            • +1

              Вот есть у нас Рельсы. В Рельсах батарейки всевозможных форм и расцветок. Всё оттестировано и работает, есть комьюнити, есть заданные и разжеванные типовые вопросы.


              Но они взяли и пошли всё переписывать на js,
              где батарейки раскиданы по буквально сотням отдельных забрашиваемых в течение месяца конкурирующих пакетов,
              где перед тем чтобы писать код надо наворотить конфигов для транспиляторов, потому что "ой, эта фича поддерживается тобько вот в таких-то версиях ноды и браузеров",
              где ещё год назад тонули в колбеках и лесенках из фигурных скобок,
              где код "выглядит синхронным, но асинхронен",
              где документация не поспевает за релизами библиотек.


              Они говорят, что Рельсы больше не нужны и все должны погрyжаться в этот адок.
              Зачем?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.