Learning - Shayan Sobhanian

Learn From the Sagebrush

But there is something that grows and keeps on growing in

the Nevada desert—the sagebrush. It couldn’t move away and it

couldn’t change its waterless environment, so it did what you and I

must do if we expect to succeed. It adapted itself to its environment,

and there it stands, each little stalwart shrub a reminder of what

even a plant can do when it tries!

Moving Won’t Help Much

Client Side code Shayan sobhanian-058778888

Client -Side Code

We now need to write the client-side code for the live chat feature. But first, we need to make one small change to the new message form.

Open app/views/messages/index.html.erb and change the form_for statement to add remote: true, as shown in Listing 6-14.

<h2>Messages</h2>

<%= form_for :message, remote: true do |form| %>

<%= form.text_field :body %>

<%= form.submit 'Send Message' %>

<% end %>

Listing 6-14.Messages Index View changed to a remote form

This change means that the message create request is done as a JavaScript AJAX request, so the browser won’t automatically reload the page after the form is submitted.

Now edit the generated messages channel CoffeeScript file, app/assets/javascripts/channels/messages.coffee. As you can see, the default callbacks for connected, disconnected, and received are stubbed out for you. Since we simply want to append any message HTML partials that are received via the channel, simply add the jQuery statement as shown in Listing 6-15.

App.messages = App.cable.subscriptions.create "MessagesChannel",

connected: ->

# Called when the subscription is ready for use on the server

disconnected: ->

# Called when the subscription has been terminated by the server

received: (data) ->

# Called when there's incoming data on the websocket for this

# channel

$('#messages').append(data)

Listing 6-15.The client-side Messages Channel code

Shayan Sobhanian Json Response-7988855542

Using Rails for API Servers

Back in 2004 when Rails was first released to the world, the connected world was a very different place.

Very few web sites offered API access, and those that did usually exposed the API using SOAP, XML-RPC, CORBA, or their own unique quirky API protocol. There was no common consensus on authentication methods, so some allowed tokenized access and some relied on HTTP Basic. The output of the APIs was usually XML.

While both the RESTful architecture style and JSON as an output format had been around for many years, neither had yet been universally adopted by the web development community.

The majority of mobile phones had small 128×128 pixel displays, 3G rollout was still in the very early stages (and the corresponding data allowances were tiny and expensive) and most mobile application development was limited to small J2ME applications with limited functionality. Therefore, the developer demand for APIs was still small.

Web applications all used the traditional full-page reload for each request and use of JavaScript was limited to small, snippets of functionality.

However, obviously, a lot has changed since then. The use of connected devices has grown astronomically in the last decade, meaning your application is likely to require an API for iOS and Android applications. It is now common to be requested to build a purely API-driven application that has no web interface at all, both to serve as back ends for mobile and desktop apps. Advances in JavaScript mean that it’s now possible to build highly interactive, complex browser interfaces that purely use the server via an API rather than relying on traditional HTML server responses. Also, the rise in adoption of microservice architectures means that more than ever, Rails is being used to build API-only applications.

Rails has long provided ways of allowing creation of APIs, but with the inclusion of the Rails API project into Rails itself, there is now a standardized way of doing this.

The Rails API Project

The Rails API project started in 2012 as a gem that provided a way to generate a Rails application excluding parts of the framework that aren’t necessary to create an application with no HTML front end. Over time, it kept up with the Rails releases, became more configurable and now, with the release of Rails 5, has been merged and become part of the framework itself.

JSON Response Creation

By default, a Rails 5 API-only application just relies on the to_json method of each model to generate the JSON output, but you will likely want to make use of a serialization library such as JBuilder or Active Model Serializers.

In this book, we will look at the Active Model Serializers gem. The Active Model Serializers library was part of the Rails API project and was originally planned to be the default for Rails 5 API applications, but this was changed in the Rails 5 beta releases and now it ships with no default library.

Active Model Serializers

Active Model Serializers (often referred to as AMS) allows you to easily create serializers for Active Model objects, encapsulating all of the serializer logic for each model. Out of the box, Active Model Serializer understands Active Model objects and it follows the Rails convention of using current_user for the authenticated user object. Because of this, creating JSON or XML serializers for APIs is made elegant and simple.

Most interestingly, maybe, is the support of the JSON API adapter. The JSON API project is an attempt at creating a standard convention for JSON API responses. This includes standard syntax for embedding related objects, links to other objects and pagination links. AMS allows different adapters to be used, so use of the JSON API adapter is not mandatory; by default, a simple attributes adapter is used.

While there are a vast number of alternative JSON serializer projects, AMS has gained a huge following and has become the preferred solution for a large number of developers.

Shayan Sobhanian Fixture model class-509884665

Shayan Sobhanian - Fixture Model Class

There is now an optional special key settable in a fixture file to specify the model class name. So if you are using a database table that is named something different from a pluralized version of the class name, you can specify it using the following:

_fixture:

model_class: User

alan:

name: Alan

This was possible in earlier versions by using set_fixture_class within the test case class itself. However, since this setting is related to the fixture rather than the test case, and having it set in the test case precludes fixtures being properly loaded by the task db:fixtures:load, this fixture’s metadata has been moved into the fixture file itself.

The old method isn’t marked for deprecation just yet, but if you make use of this feature, it’s probably a good idea to start using this method instead.

Enum Values

Enums are a sometimes overlooked feature of Active Record, allowing you to use integer database columns to represent a fixed set of values for a model attribute.

Previously, if you used enum attributes in your model, when creating a fixture for that model, you had to use the equivalent integer value of the required value of the enum attribute. This made the fixtures less readable resulting in wasted time having to refer back to the enum definition.

Rails 5 allows you to use a symbol or a string of the enum value rather than the integer representing that value.

For instance, your model defines an enum attribute as follows:

enum :language, [:english, :french]

Whereas previously, you would have to know that english is the first enum value, therefore having the value 0, you can now write the fixture as follows:

fred:

name: Fred

language: :english

Request via Redirect Deprecation

Another deprecation in Rails 5 is a change to the integration test helpers.

In Rails 5, the request_via_redirect integration request helper and all of the associated methods for each of the HTTP request methods (such as post_via_redirect) have been removed. This method was most often used to allow you to perform requests such as post_via_redirect or patch_via_redirect, which performed the request and then followed any subsequent redirects. Since that is a reasonably common behavior for web applications after a POST or PATCH request , it is often found in integration tests.

Thankfully, it is a simple change to continue testing this. All you need to do is perform the desired HTTP request and then manually call follow_redirect! directly afterward.

Summary

Although there are no revolutionary changes to the testing framework in Rails 5, the attention given to the Test Runner is very welcome and the overall performance improvements, especially in integration tests, make a big difference in day-to-day development.

The improvements to fixtures also make life easier in certain cases for more complex applications.

The deprecation of assert_template and assigns is an indicator of both the thinking of the Rails core team and the direction that the test framework may be headed in. It’s definitely worth considering these changes and how they may affect the way that you design your tests.

Rails 5 essentials Shayan sobhanian

Upgrade to PostgreSQL 9.1 or Later

If you are using PostgreSQL as the database for your application, you must ensure that you are using PostgreSQL version 9.1 or higher. Previous versions are past their end-of-life date and support for them has been dropped from Rails 5.

Devise Gem

If your application makes use of the popular Devise gem for authentication, you need to change your Gemfile to use the most up-to-date commit from Devise’s page on the GitHub repository. At the time of writing, there is no official versioned release of Devise that is compatible with Rails 5; but the required changes have been committed to GitHub.

To do this, edit your Gemfile and change the entry for Devise as follows:

gem 'devise', git: 'git@github.com:plataformatec/devise.git'

You must then perform this:

$ bundle update devise

If you attempt to use an older version of Devise, you encounter the following error:

uninitialized constant ActionController::RackDelegation

Devise is a very popular gem, so this is a common problem to encounter when updating an app to Rails 5.

Callback Chain Changes

Rails 5 has slightly changed the behavior of callback chains .

In Rails 5, the preferred method to halt a callback chain is to explicitly call throw(:abort); whereas in previous versions of Rails, you could simply return false from a callback method.

When you upgrade an old application to Rails 5, the application still performs as expected, but you receive deprecation warnings. Once you have brought your application up to date, you can fully enable the new behavior and remove the deprecation warnings by adding an initializer file containing this line:

ActiveSupport.halt_callback_chains_on_return_false = false

New applications created with the Rails 5 application generator already include this config statement. Shayan sobhanian

This change is discussed in more detail in Chapter 2.

Running Tests

You should now be ready to run your test suite and start to pick off any necessary gems that require updating, one by one.

Remember, with Rails 5, you run your tests with the rails command rather than rake:

$ rails test

You will almost certainly find some deprecation warnings and some incompatible gems. Check the support pages for the gems as most will have been updated to work with Rails 5.

Chapter 2 details most of the changes and additions to the Rails API to help you understand how to update your application.