Rails 5 is right around the corner (currently targeting Fall 2015) and there are some exciting features coming up. If you are running a Rails shop, you need to prepare your apps for this major release.
Don’t worry. As always, we at Sitepoint will guide you throughout the migration process when the release date approaches. For now, let’s catch you up on what’s coming and how it will improve your development process.
There are some amazing announcements that will fundamentally shift how we work with Rails. New features like Action Cable and improved Turbolinks that can instantly improve our web development workflow. Let’s look at each of them in detail.
Merging Rails API
Over the last few years, many thanks to Backbone.js and Angular.JS, the number of Single Page Applications (SPAs) are on the rise. The last few projects that I have built have been purely SPA and using Rails for these cases was an overkill. I tried dabbling with Sinatra and even pure Rack applications, but ended up writing too much boilerplatee. The routing was lacking compared to Rails and there were too many security vulnerabilities that I had to handle. I had to either write it on top of the community driven rails-api gems or live with traditional Rails.
Ruby 2.2 was a great addition to the Ruby community. Not only did it bring a huge performance boost to Ruby, but it also introduced a slew of new functions. In addition, garbage collection of symbols was widely celebrated. Legend has it that Dragons of Valeria rained down rose petals on the Seventh Kingdom when this announcement was made. OK! Maybe I took that too far, but you get the general picture.
NOTE: Before migrating to Rails 5 you need to make sure that your app works on Ruby 2.2.1.
Due to these enhancements, Ruby 2.2+ was a ripe candidate for Rails 5. Rails 5 will only work on Ruby 2.2.1 and above.
Traditional web apps tend to be slow due to full page reloads. One way to solve this is just reloading the bare minimum content area. Turbolinks solve this by just reloading the contents of the body from the server, instead of refreshing the entire page. While this improves the performance to a certain extent, this is also relatively slow. Turbolinks 3 aims to solve this.
Tubolinks 3 allows you to retain most of your page and selectively update certain regions through partials. This is very similar to how SPA’s work, and you can choose to do all this from the server. Sounds great, right?
This is a great feature as the flock moves towards single page apps. However, at first glance, it looks like you’ll have to manage the partials manually. This means that you’ll have to remember which part of the app to reload at a specific point. To me, it adds a lot of clutter to my code and makes it easy to screw up. Personally, I prefer using something like React, which handles this very well with the Virtual DOM.
Note: The way React works is, it maintains a Virtual DOM where all the manipulations happen. It then diff’s the Virtual DOM and the actual DOM and makes only the required changes. It ensures that DOM is hit only when absolutely required and the changes are bare minimum.
Having said that, for the folks who don’t like to meddle around with JS, this offers an instantaneous performance boost.
Many projects these days use WebSockets to push live updates to the client. While most client browsers have started to support this, we still need a robust client on the server to manage the subscribers and send an update signal appropriately. This feature is available out of the box in some of the newer frameworks, like Phoenix for Erlang. However, the Rails community had to resort to third party implementations, like Pushr, to get this working.
Note: For the uninitiated, WebSockets is a W3C standard that opens up a duplex connection from your browser. Servers can talk (i.e., push updates) to clients as needed, and asynchronously update the client’s state without a full page reload. For instance, this is how Gmail loads new emails without reloading the entire page.
Rails traditionally offers all the tools that one needs to build a great app out of the box. That’s one reason why it is so popular, especially among the startup community. The lack of WebSocket support was a reason for major discontent among the community. It looks like the Rails core team took note of this and came up with Action Cable. We’ll have to wait for some time to see how this is going to work in real life, but it’s exciting nevertheless.
Rake Inside Rails
For many a Rails noob, having to figure out when to use
rake and when to use
rails is a source of confusion. Now you don’t need to switch context between the
rails commands. You can run all Rake tasks with the
rails keyword. For instance,
will now become:
This may not look like much on the surface, but this will make the lives of beginners much simpler. Rails 5 will also add a
restart command that quickly restarts the application.
Active Record Changes
One change that almost went unnoticed was the update to
belongs_to. When you create a Student
belongs_to Class relation, it was possible to create a student without an associated Class relation. This lead to a lot of data inconsistencies. With Rails 5, he parent has become mandatory. If you try to insert an empty record here, Active Record will throw up.
Changes to Controller Tests
If you’re testing what your template renders in your controller, you are doing it wrong. A simple change to your template will leave you with sleepless nights, hunting down the culprit. That’s why, in Rails 5,
assert_template is deprecated. However, you can continue using
assert_select to check if a specific DOM element is present.
If you’ve been testing the instance variables inside a controller method, you should note that
assigns is also going away.
If you’re writing controller tests, the new decree is that you should be concerned with cookies, HTTP return code, and DB calls, if any. Wait, that sounds just like an integration test. Well, you got me there…controller tests will likely be dropped in favor of integration tests in the future.
Note:* Checkout Rails Dom testing for more details and best practices.
Hola! I'm a Fullstack developer and a strong advocate of Mobile first design. I'm running a digital children's startup for kids and I lead the engineering efforts there. In my free time I ramble about technology, and consult startups.