Rails: ¡Mira mamá! ¡Sin JavaScript! » Ruido blanco

Los mayores siempre han dicho que el JavaScript no debe ser esencial para el funcionamiento correcto de la página, que un usuario sin JavaScript activado debe ser capaz de realizar las mismas funciones básicas que un usuario con JavaScript activado. ¿Cumple Rails con este principio o debe el desarrollador poner trabajo de su parte?

El origen del problema

Un enlace a una página web utiliza para obtener la página de un servidor el “verbo” (método) GET de HTTP, que según las reglas tiene que ser idempotente, es decir, no debe modificar el estado en el servidor, para ese fin están otros “verbos” como POST, y los menos conocidos PUT y DELETE (existen al menos otros cuatro más).

Normalmente para enviar datos al servidor se utilizan formularios, a los que mediante un atributo se les puede pedir que envien los datos al servidor utilizando el “verbo” POST. Para borrar datos, sin embargo, no necesitamos proporcionar ningún dato a ningún formulario, por lo que es más “sencillo” (desde el punto de vista del usuario) y visualmente más agradable que la acción de eliminar (o votar, o lo que sea) se dispare utilizando un enlace. El problema del enlace es que sólo sabe hacer GET y ya hemos dicho que ese era un “verbo” idempotente.

¿Y para seguir el estándar vamos a dejarlo todo feo poniendo un horrible botón? Bueno, si la solución del botón no es aceptable y seguir el estándar no parece una gran razón quizá Google (y los demás buscadores) sí lo sea. Cuando Google mira las páginas web que tiene indexadas sigue (casi) todos los enlaces, por lo que si tienes un digg con un montón de enlaces de “votar” Google los seguirá todos, haciendo que tu ranking se llene de votos falsos.

Y todos diremos “seguro que por eso digg requiere registro”. De acuerdo, Google no vota porque no tiene usuario, pero resulta que hace unos años Google se sacó de la manga Google Web Accelerator (no, si la culpa al final va a ser de Google), una especie de proxy de escritorio que descargaba por adelantado las páginas enlazadas desde la página que el usuario estaba visitando en ese momento. Y el usuario sí está registrado. Quizá los votos falsos no sean un problema demasiado grave, pero eliminar una reunión, añadir un artículo al carrito o eliminar el artículo que habíamos añadido quizá sí sean problemáticos (y sobre todo molestos para el usuario).

En resumen, los enlaces no deben utilizarse para modificar el estado en el servidor.

El problema en Rails con arquitectura “clásica”

Vale, pero esto iba de Rails ¿no? Sí, a eso iba. Desde hace muchas versiones Rails permite generar un enlace que realice una petición POST al servidor (dentro de un momento vemos cómo) añadiendo la opción :method => :post (en Rails 1.2 y superiores) o :post => true (antes de Rails 1.2) y además permite proteger las acciones de los controladores para que sólo respondan a un verbo o a otro (utilizando el método verify o discriminado con request.post?).

Desgraciadamente el scaffolding por defecto de Rails (1.2, pero en la 1.1 era parecido) genera lo siguiente para el controlador (omito lo que no me interesa):

# GETs should be safe (see http://www.w3.org/2001/tag/doc/whenToUseGet.html)
verify :method => :post, :only => [ :destroy, :create, :update ],
  :redirect_to => { :action => :list }

def destroy
  Product.find(params[:id]).destroy
  redirect_to :action => ‘list’
end

Y lo siguiente para la vista:

<td><%= link_to 'Destroy',
  { :action => ‘destroy’, :id => product },
  :confirm => ‘Are you sure?’,
  :method => :post %></td>

Es decir, en el controlador verifica que el método con el que se llama a la acción destroy es POST y los enlaces los genera para utilizar el método POST.

Pero si un enlace siempre es GET, ¿cómo hace Rails para que se envíe un POST? Bueno, pues hace trampas utilizando JavaScript. Rails genera lo siguiente para el anterior enlace:

<td><a href="/products/destroy/1"
  onclick=”if (confirm(’Are you sure?’)) {
    var f = document.createElement(’form’);
    f.style.display = ‘none’;
    this.parentNode.appendChild(f);
    f.method = ‘POST’;
    f.action = this.href;
    f.submit();
  };
  return false;”>
Destroy
</a></td>

Todo ese trozito de JavaScript viene a decir más o menos: cuando me pinchen crea un formulario aquí al lado, que se invisible, cuyo método sea POST y su URL la URL del enlace, y envía ese formulario. De esta forma Rails recibirá una petición POST y no GET cuando se pinche en el enlace.

¿Pero que pasa si el usuario no tiene JavaScript activado? Bueno, pues no pasa nada (para tragedia del usuario). El enlace generaría una petición GET que Rails, de acuerdo al método verify del controlador, rechazaría y enviaría al usuario de nuevo a la acción list.

Pero como nos gusta ser buenos desarrolladores web tenemos que proporcionar al usuario un método para eliminar los registros incluso si no tiene JavaScript activado en el navegador. Lo mejor es que es muy sencillo.

Lo primero que hay que hacer es quitar la acción destroy de la lista de acciones del método verify y modificar el método destroy para que aparezca de esta forma:

def destroy
  return if request.get?
  Product.find(params[:id]).destroy
  redirect_to :action => ‘list’
end

La primera línea (la única que hemos incluido) hace que Rails represente la vista destroy.rhtml en el caso de que la petición sea un GET, pero cuando es un POST se sigue ejecutando el método, realizando el borrado deseado.

Ahora solo falta incluir en la vista un formulario de confirmación para el usuario (aderezar al gusto, esto sólo es un ejemplo).

<% form_tag nil, :method => 'post' do %>
<% submit_tag ‘Eliminar’ %/>
<% end %>

¿Sencillo, no? Pues los desarrolladores de Rails, con lo listos que son, no parece importarles mucho que JavaScript esté desactivado.

Pero aún hay otros puntos en Rails donde JavaScript es “obligatorio” a menos de que proporcionemos el “camino alternativo”. Los métodos implicados son link_to_remote, link_to_funcion y form_remote_tag / form_remote_for.

link_to_remote y link_to_function se arreglan igual. El primero realiza una llamada mediante XMLHttpRequest (aka AJAX) para actualizar la página, mientras que al segundo se le puede proporcionar el código JavaScript a ejecutar. A ambas se les puede proporcionar una opción de “baja tecnología” pasando el parámetro :href con una URL (una cadena o una de las funciones de Rails para generar las URL de la aplicación) que se utilizará cuando el navegador del usuario no ejecute JavaScript.

Para form_remote_tag y form_remote_for el parámetro se llama :html y acepta un hash de las opciones que se pasarían normalmente al método form_for (:action y :method).

El truco está en desarrollar la aplicación como si no existiera JavaScript, y sólo después añadir lo necesario para que JavaScript mejore la experiencia de usuario.

El problema en Rails con arquitectura REST

En Rails 1.2 han introducido (con mucha insistencia) facilidades para crear una arquitectura REST, que en resumen se trata de utilizar los cuatro verbos apuntados al principio (GET, POST, PUT, DELETE) sobre URL que no representan documentos, sino recursos. La ídea es muy útil porque simplifica mucho el desarrollo de API para la utilización de los recursos representados por una aplicación web externamente. La verdad es que yo me explico fatal… pero quizá este relato de como alguién se lo explicó a su mujer ayude.

Como decía la idea es buena, pero los navegadores actuales sólo envian peticiones mediante GET y POST, por lo que hay que buscarse la vida para simular las peticiones DELETE y PUT, y los desarrolladores de Rails lo han hecho utilizando tanto JavaScript en el lado del cliente como un poco de código en el lado del servidor.

Cuando en Rails 1.2 pedimos un link_to utilizando :method => :delete Rails genera un código parecido al que hemos visto antes con el método POST, pero incluye además otro campo oculto en el formulario llamado _method con valor delete. Rails en el servidor hará que parezca que el método ha llegado a través de una petición DELETE en vez de POST.

Como en el anterior caso, los desarrolladores de Rails no han pensado en la gente que no navega con JavaScript activado, y lo que es peor, como en REST las URL representan resursos no hay forma de proporcionar una solución de “baja tecnología” sencillamente.

Digamos que el recurso que queremos eliminar es un “producto” y tiene identificador 1. Según REST su URL sería /products/1. Sobre esta URL se puede actuar con el método GET para recuperar la información del producto, con el método PUT para actualizarla y con el método DELETE para eliminarlo. En el caso de una arquitectura no-REST la URL /products/destroy/1 podía servirnos para mostrar la confirmación de eliminación si el método era GET y borrar el producto si el método era POST.

Por suerte Rails sabe que no sólo de crear, leer, modificar y eliminar vive el hombre, por lo que proporciona un método para definir “acciones” adicionales (pero siempre utilizando los cuatro “verbos” de HTTP). Por ejemplo, cuando con una línea como la siguiente en routes.rb creamos un recurso:

map.resources :products

Rails genera una serie de rutas, entre ellas GET /products/new y GET /products/:id/edit (sí, eso es un punto y coma en Rails 2 ya no se utilizan los punto y coma), que permiten al usuario de la aplicación web ver el formulario donde introducir los datos que posteriormente se enviarán a POST /products (en el caso de querer crear un nuevo recurso) o PUT /products/:id (en el caso de querer editar un recurso existente). Es decir, esas rutas son sólo “para humanos”: muestran un formulario con el que los humanos interactuan.

Siguiendo la metafora si POST tiene /new y PUT tiene /edit, sería lógico que DELETE tuviera /delete /remove. Para ello necesitamos modificar el archivo routes.rb de la siguiente manera:

map.resources :products, :member => { :delete => :get }
map.resources :products, :member => { :remove => :get }

El código de la acción delete remove en el controlador es igual que el de edit:

def delete
def remove
  @product = Product.find(params[:id])
end

Y el código de la vista (delete.rhtml remove.rhtml) muy parecido al anterior:

<% form_tag product_url(@product), :method => :delete do %>
<%= submit_tag ‘Eliminar’ %>
<% end %>

Ahora llegamos al problema. link_to acepta un solo URL, ¿cuál usamos? Si utilizamos delete_product_url(@product) remove_product_url(@product) la gente con JavaScript desactivado obtendría la página de confirmación, pero la gente con JavaScript activado obtendría un RoutingError al no existir una ruta DELETE /products/:id/delete DELETE /products/:id/remove. Si utilizamos product_url(@product) el código JavaScript funcionará pero los usuarios sin JavaScript verán la página asociada al recurso.

A partir de aquí hay dos soluciones, una incluida en Rails y otra “parcheando” Rails. La solución incluida en Rails es utilizar link_to_remote en vez de link_to, ya que el objeto XMLHttpRequest soporta todos los métodos de HTTP y utilizar el parámetro :href para proporcionar la solución de “baja tecnología”.

Lo primero que hay que hacer es incluir la librería de Prototype en la cabecera de nuestra página (posiblemente en algún layout):

<%= javascript_include_tag 'prototype' %>

Luego modificaremos el código de index.rhtml para incluir un id único a cada una de las filas de nuestra tabla (utilizad dom_id, incluido en Rails) y modificaremos el enlace del “Destroy” por nuestro link_to_remote:

<tr id="<%= dom_id(product) %>">
  <!– … –>
  <td><%= link_to_remote ‘Destroy’,
    { :url => product_path(product),
    :method => :delete },
    :href => delete_project_path(project) %>
    :href => remove_project_path(project) %>
  </td>
</tr>

En el controlador habrá que modificar el método destroy para que se parezca a lo siguiente:

def destroy
  @product = Product.find(params[:id])
  @product.destroy

  respond_to do |format|
    format.html { redirect_to products_url }
    format.js # destroy.rjs (linea añadida)
    format.xml { head :ok }
  end
end

Y por último deberemos crear el archivo destroy.rjs que será devuelto al navegador:

page.remove “product-#{@product.id}”
page[@product].remove

Y tenemos un precioso enlace Google-friendly que en un navegador con Javascript hace que la fila destruida desapareza. No está mal para un par de minutos de trabajo.

La otra solución, la que implica “parchear” Rails consiste en descargar link_to_rest_url_patch.rb, dejarlo en el directorio lib de nuestra aplicación y añadir la línea require 'link_to_rest_url_patch' en environment.rb.

El problema actual de link_to es que utiliza la misma URL como destino del enlace y como action del formulario que genera dinámicamente. Como nosotros necesitamos una URL en un caso y otra URL en otra tenemos que sacarla de algún lado.

El parche modifica unos métodos que link_to utiliza para que acepten un parámetro nuevo denominado :rest_url que será la URL que se utilice como action del formulario generado dinámicamente, mientras que la URL del segundo parámetro de link_to se utilizará como destino del enlace. Si no se proporciona el parámetro :rest_url se utilizará la URL del segundo parámetro en ambos casos (que es el funcionamiento sin el parche).

Como podéis ver no es tan difícil proporcionar alternativas a los enlaces que utilicen exclusivamente JavaScript. Además proporcionando alternativas llegamos a un público mucho más amplio mientras que seguimos proporcionando una experiencia satisfactoria a los usuarios tecnológicamente más avanzados.

Ver entradas relacionadas

• Seminario de Ruby on Rails: Presentación
• De como ser vago te evita escribir dos páginas de tutorial
• The JavaScript Raytracer
• Rails: :dependent => :protect plugin
• Seminario de Ruby on Rails