Did you know that you don't need to use the begin/rescue/end pattern within a Ruby method definition body? If you do, you might have tried like me to apply an inline rescue statement with no begin or end inside of a normal Ruby block, say a block passed to Array#each for example.
But... it doesn't work. Although it works fine inside method bodies, this is invalid syntax in Ruby 2.4 and prior, which is kind of infuriating because putting a rescue statement at the same nesting level as the do statement makes rescue operation very neatly visible.
Thanks to Josh Cheek however, this oddity will disappear from Ruby 2.5 which should arrive this coming Christmas.
One caveat is that the new behavior will not apply to blocks created with curly braces instead of do/end keywords. Which honestly makes a lot of sense.
But since the release of Rails 5.1 in late April, a much smoother bridge now exists — beyond Sprockets — between the Rails world and the front-end world.
First, Yarn, which arrived in late 2016 and finally brought the crucial enhancements npm sadly failed to bring for years: lockfile support just like Bundler, and faster dependency resolution and download. Yarn is now a first class citizen in the Rails ecosystem with its own bin/yarn command.
Second, webpack which can replace Sprockets in the often complicated task of bundling multiple different assets together into one application package for the production environment. Rails 5.1 brought along the webpacker gem which brings a much appreciated tighter integration of Webpack into Rails, to avoid having to deal with heaps of configuration.
So while I still default to Sprockets in most of my Rails applications, if I'm ever going to integrate a front-end stack driven by React, Angular, Vue, or Ember then I'm most likely going to reach for Webpack.
By integrating Capybara natively with a default Selenium Chrome driver, Eileen has not only made it easy to really test your Rails application as a user would in their browser, she's also solved some very problematic issues with the way those integration tests behaved in the past.
This is something that was solved in Rails 5.1 by Matthew Draper. The system test opens a connection to the database that is then shared with the headless browser so they both see the same temporary database records. This alone is going to simplify user-focused feature testing a lot.
Just as I was finishing this episode, DHH released a new gem called Active Storage. The goal is to finally address the issue of having to store data on a remote server like Amazon S3 which used to require gems like CarrierWave or Paperclip.
On his blog, Mike Gunderloy went over the basic setup and interface which allows you to use the usual file_field form helper after defining sort of a virtual association inside your models. For instance, a User can define has_one_attached :avatar and Active Storage will take care of uploading the data submitted to the form straight to the storage provider.
This won't be available inside of Rails until Rails 5.2 but nothing prevents you from testing it with rails master.