09-errors.md.erb

---
title: Errores
slug: errors
date: 0009/01/01
number: 9
points: 10
photoUrl: http://www.flickr.com/photos/ikewinski/9413892879/
photoAuthor: Mike Lewinski
contents: Crearemos un mecanismo mejorado para mostrar errores y mensajes.|Implementaremos validaciones más estrictas|Mostraremos errores en línea para los formularios.
paragraphs: 31
---

Resulta poco elegante usar un `alert()` para advertir al usuario de que algo ha pasado. Hay que hacerlo mejor.

Vamos a construir un mecanismo de presentación de errores más versátil y que va a hacer mejor el trabajo de informar al usuario sobre lo que está pasando sin tener que romper su flujo de trabajo.

Vamos a implementar un simple sistema que muestre los nuevos errores en la parte de arriba a la derecha de la ventana, de forma similar a la popular aplicación [Growl](http://growl.info/) de MacOS.

### Introduciendo las colecciones locales

Para empezar, crearemos una colección para almacenar nuestros errores. Puesto que los errores solo son relevantes en la sesión actual y no necesitan ser persistentes, haremos algo nuevo, vamos a crear una *colección local*. Es decir, la colección `Errors` solo existirá *en el navegador*, y no se sincronizará con el servidor.

Para conseguirlo, creamos la colección dentro del directorio `client` (para hacer que sólo esté disponible en la parte cliente), con el nombre de la colección establecido a `null` (ya que los datos nunca se almacenarán en la base de datos del servidor):

~~~js
// Local (client-only) collection
Errors = new Mongo.Collection(null);
~~~
<%= caption "client/helpers/errors.js" %>

Ahora que hemos creado la colección, podemos agregar una función `throwError`, que usaremos para añadir errores. Al tratarse de una colección local, no tenemos que preocuparnos por definir `allow` o `deny` u otros mecanismos de seguridad, ya que esta colección es “local” para el usuario actual.

~~~js
throwError = function(message) {
  Errors.insert({message: message});
};
~~~
<%= caption "client/helpers/errors.js" %>

La ventaja de utilizar una colección local para almacenar los errores es que, como todas las colecciones, es reactiva -- lo que significa que podemos mostrar errores de la misma forma que mostramos cualquier otro dato de una colección.

### Mostrando Errores

Mostraremos los errores en la parte de arriba de nuestro layout:

~~~html
<template name="layout">
  <div class="container">
    {{> header}}
    {{> errors}}
    <div id="main">
      {{> yield}}
    </div>
  </div>
</template>
~~~
<%= caption "client/templates/application/layout.html" %>
<%= highlight "4" %>

Ahora vamos a crear la plantilla de error en `errors.html`:

~~~html
<template name="errors">
  <div class="errors">
    {{#each errors}}
      {{> error}}
    {{/each}}
  </div>
</template>

<template name="error">
  <div class="alert alert-danger" role="alert">
    <button type="button" class="close" data-dismiss="alert">&times;</button>
    {{message}}
  </div>
</template>
~~~
<%= caption "client/templates/includes/errors.html" %>

<% note do %>

### Dos plantillas en un archivo

Te habrás dado cuenta de que estamos definiendo dos plantillas en un solo archivo. Hasta ahora hemos tratado de mantener la regla "un archivo, una plantilla", pero con Meteor podemos poner todas las plantillas en un único fichero y también funcionaría (¡Aunque tendríamos un fichero `main.html` muy confuso!).

En este caso, como las plantillas son muy pequeñas, haremos una excepción y las pondremos en el mismo fichero para que nuestro repositorio quede un poco más limpio.

<% end %>

Solo nos falta integrar el ayudante de plantilla y ¡Estará listo!

~~~js
Template.errors.helpers({
  errors: function() {
    return Errors.find();
  }
});
~~~
<%= caption "client/templates/includes/errors.js" %>

Ya puedes probar nuestros mensajes de error manualmente. Abre una consola en el navegador y escribe:

~~~js
throwError("I'm an error!");
~~~

<%= screenshot "9-1", "Probando mensajes de error." %>

<%= commit "9-1", "Mostrando errores." %>

<% note do %>

### Dos clases de errores

Llegados a este punto es importante hacer distinción entre los errores a “nivel de aplicación” y los errores a “nivel de código”.

Los errores a **nivel de aplicación** son, generalmente, generados por el usuario, y los usuarios pueden interactuar con ellos. Esto incluye cosas como los errores de validación, errores de permisos, errores de “no encontrado”, etc. Estos son la clase de errores que queremos mostrar al usuario para ayudarle a arreglar el problema que hemos encontrado.

Los errores a **nivel de código**, en cambio, se generan de forma inesperada por fallos en nuestro código, y que probablemente *no* queremos mostrarle al usuario directamente, si no que queremos registrarlo con alguna clase de sistema de registro de errores (como por ejemplo [Kadira](http://kadira.io)).

En este capítulo, nos centraremos en tratar con el primer tipo de error, no en capturar fallos.

<% end %>

### Creando errores

Ya sabemos cómo mostrar los errores, pero todavía tenemos que crearlos antes de poder verlos. Ya hemos implementado un buen escenario para mostrarlos: el aviso de post duplicado. Sencillamente remplazaremos las llamadas a `alert` en el ayudante de eventos de `postSubmit` con la nueva función `throwError` que acabamos de crear:

~~~js
Template.postSubmit.events({
  'submit form': function(e) {
    e.preventDefault();

    var post = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    };

    Meteor.call('postInsert', post, function(error, result) {
      // display the error to the user and abort
      if (error)
        return throwError(error.reason);

      // show this result but route anyway
      if (result.postExists)
        throwError('This link has already been posted');

      Router.go('postPage', {_id: result._id});
    });
  }
});
~~~
<%= caption "client/templates/posts/post_submit.js" %>
<%= highlight "13,17" %>

Ya que estamos, hacemos lo mismo con el ayudante de `postEdit`:

~~~js
Template.postEdit.events({
  'submit form': function(e) {
    e.preventDefault();

    var currentPostId = this._id;

    var postProperties = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    }

    Posts.update(currentPostId, {$set: postProperties}, function(error) {
      if (error) {
        // display the error to the user
        throwError(error.reason);
      } else {
        Router.go('postPage', {_id: currentPostId});
      }
    });
  },
  //...
});
~~~
<%= caption "client/templates/posts/post_edit.js" %>
<%= highlight "15" %>

<%= commit "9-2", "Usando el mecanismo de presentar errores." %>

Vamos a probar: intenta crear un post e introduce la URL `http://meteor.com`. Como esta URL ya existe en un post en nuestros datos de ejemplo, deberíamos ver:

<%= screenshot "9-2", "Disparando un error" %>

### Limpiando los errores

Te habrás dado cuenta de que los mensajes de error desaparecen por sí mismos después de unos segundos. Esto es debido un poco de magia CSS incluida en la hoja de estilos que hemos añadido al principio del libro:

~~~css
@keyframes fadeOut {
  0% {opacity: 0;}
  10% {opacity: 1;}
  90% {opacity: 1;}
  100% {opacity: 0;}
}

//...

.alert {
  animation: fadeOut 2700ms ease-in 0s 1 forwards;
  //...
}
~~~
<%= caption "client/stylesheets/style.css" %>

Estamos definiendo una animación CSS `fadeOut` que especifica cuatro keyframes para la propiedad opacidad (al 0%, 10%, 90% y 100% del total de la duración de la animación), y aplicando esta animación a la clase `alert`.

La animación se ejecuta durante 2700 milisegundos en total, usa la ecuación de tiempo `ease-in`, se inicia con un retardo de 0 segundos, se ejecuta una sola vez, y finalmente permanece en el último keyframe una vez que se ha terminado de ejecutar.

<% note do %>

### Animaciones contra Animaciones

Te estarás preguntando porqué estamos usando animaciones basadas en CSS (que son predeterminadas y están fuera del control de nuestra aplicación), en lugar de animaciones controladas por el propio Meteor.

Si bien Meteor proporciona soporte para insertar animaciones, queríamos en este capítulo enfocarnos en los errores. Así que, por ahora, usaremos una “simple” animación CSS y dejaremos esas cosas para el capítulo de las animaciones.

<% end %>

Esto funciona, pero si lanzamos varios errores (enviando el mismo enlace tres veces por ejemplo) notarás que se apilarán uno encima de otro:

<%= screenshot "9-3", "Stack overflow." %>

Esto pasa porque mientras los elementos `.alert` están desapareciendo *visualmente*, todavía están presentes en el DOM. Necesitamos corregir esto.

Esta es la clase de situaciones en las que Meteor reluce. Puesto que la colección `Errors` es reactiva, ¡Todo lo que necesitamos para deshacernos de estos antiguos errores es eliminarlos de la colección!

Usaremos `Meteor.setTimeout` para especificar una función que se ejecute después de que se expire el tiempo de espera (en este caso, 3000 milisegundos).

~~~js
Template.errors.helpers({
  errors: function() {
    return Errors.find();
  }
});

Template.error.onRendered(function() {
  var error = this.data;
  Meteor.setTimeout(function () {
    Errors.remove(error._id);
  }, 3000);
});
~~~
<%= caption "client/templates/includes/errors.js" %>
<%= highlight "7~12" %>

<%= commit "9-3", "Limpiar errores después de 3 segundos." %>

La llamada a [`onRendered`](http://docs.meteor.com/#template_onRendered) se lanza una vez que nuestra plantilla ha sido renderizada en el navegador. Dentro de esta llamada, `this` hace referencia a la instancia actual de la plantilla, y `this.data` da acceso a los datos del objeto que está siendo renderizado (en nuestro caso, un error).

### En busca de las validaciones

Aún no hemos impuesto ninguna clase de validación en nuestro formulario. Queremos que los usuarios indiquen una URL y un título para cada post. Vamos a asegurarnos de esto sea así.

Haremos dos cosas para comprobar campos ausentes: primero, añadiremos una clase css especial `has-error` al `div` padre de cualquier campo de formulario. Segundo, mostraremos un mensaje de error justo debajo del campo.

Para comenzar, vamos a preparar nuestra plantilla `postSubmit` para aceptar este nuevo tipo de ayudantes:

~~~html
<template name="postSubmit">
  <form class="main form page">
    <div class="form-group {{errorClass 'url'}}">
      <label class="control-label" for="url">URL</label>
      <div class="controls">
          <input name="url" id="url" type="text" value="" placeholder="Your URL" class="form-control"/>
          <span class="help-block">{{errorMessage 'url'}}</span>
      </div>
    </div>
    <div class="form-group {{errorClass 'title'}}">
      <label class="control-label" for="title">Title</label>
      <div class="controls">
          <input name="title" id="title" type="text" value="" placeholder="Name your post" class="form-control"/>
          <span class="help-block">{{errorMessage 'title'}}</span>
      </div>
    </div>
    <input type="submit" value="Submit" class="btn btn-primary"/>
  </form>
</template>
~~~
<%= caption "client/templates/posts/post_submit.html" %>
<%= highlight "3,7,10,14" %>

Fíjate que estamos pasando parámetros (`url` y `title` respectivamente) a cada ayudante. Esto nos permite reutilizar el mismo ayudante, modificando su comportamiento según el parámetro.

Ahora la parte divertida: hacer que estos ayudantes hagan realmente algo.

Usaremos la **Session** para almacenar un objeto `postSubmitErrors` que contendrá el potencial mensaje de error. Según el usuario interactúa con el formulario, este objeto irá cambiando, por lo que irá cambiando reactivamente el estilo y contenido del formulario.

Primero, iniciamos el objeto donde se crea la plantilla `postSubmit`. Esto nos asegura que el usuario no ve un mensaje de error antiguo que se haya quedado de una visita anterior a esta página.

Después definimos dos ayudantes de plantilla. Ambos buscarán la propiedad `field` del objeto `Session.get('postSubmitErrors')` (donde `field` será `url` o `title` dependiendo del ayudante desde que el que se llame).

Mientras que `errorMessage` solo devuelve el mensaje en sí mismo, `errorClass` comprueba la *presencia* de un mensaje y devuelve `has-error` en caso de que exista un mensaje.

~~~js
Template.postSubmit.onCreated(function() {
  Session.set('postSubmitErrors', {});
});

Template.postSubmit.helpers({
  errorMessage: function(field) {
    return Session.get('postSubmitErrors')[field];
  },
  errorClass: function (field) {
    return !!Session.get('postSubmitErrors')[field] ? 'has-error' : '';
  }
});

//...
~~~
<%= caption "client/templates/posts/post_submit.js" %>
<%= highlight "1~12" %>

Puedes comprobar que nuestros ayudantes están funcionando correctamente abriendo una consola en el navegador y escribiendo la siguiente línea de código:

~~~js
Session.set('postSubmitErrors', {title: 'Warning! Intruder detected. Now releasing robo-dogs.'});
~~~
<%= caption "Consola del navegador" %>

<%= screenshot "9-4", "¡Alerta roja! ¡Alerta roja! " %>

El próximo paso es enganchar el objeto de sesión `postSubmitErrors` al formulario.

Antes de hacerlo, crearemos una nueva función `validatePost` en el fichero `posts.js` que mire en el objeto `post`, y devuelva un objeto `errors` con cualquier error relevante (que los campos `title` o `url` no están presentes):

~~~js
//...

validatePost = function (post) {
  var errors = {};

  if (!post.title)
    errors.title = "Please fill in a headline";

  if (!post.url)
    errors.url =  "Please fill in a URL";

  return errors;
}

//...
~~~
<%= caption "lib/collections/posts.js" %>
<%= highlight "3~13" %>

Llamaremos a esta función desde el ayudante de eventos de `postSubmit`:

~~~js
Template.postSubmit.events({
  'submit form': function(e) {
    e.preventDefault();

    var post = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    };

    var errors = validatePost(post);
    if (errors.title || errors.url)
      return Session.set('postSubmitErrors', errors);

    Meteor.call('postInsert', post, function(error, result) {
      // display the error to the user and abort
      if (error)
        return throwError(error.reason);

      // show this result but route anyway
      if (result.postExists)
        throwError('This link has already been posted');

      Router.go('postPage', {_id: result._id});
    });
  }
});
~~~
<%= caption "client/templates/posts/post_submit.js" %>
<%= highlight "10~12" %>

Fíjate que estamos usando `return` para abortar la ejecución del ayudante si hay errores, no porque queramos devolver ningún valor concreto.

<%= screenshot "9-5", "Capturando errores." %>

### Validaciones en el lado servidor

¿Ya hemos terminado?. Estamos validando la presencia de una URL y un título en el lado del cliente, ¿Pero que pasa con el servidor? Después de todo, alguien podría añadir un post llamando manualmente al método `postInsert` desde la consola del navegador.

Aunque pienses que no necesitamos mostrar ningún mensaje de error en el servidor, podemos hacer uso de la función `validatePost`. Solo que esta vez la llamaremos desde el método `postInsert` también, y no sólo desde el ayudante de eventos:

~~~js
Meteor.methods({
  postInsert: function(postAttributes) {
    check(this.userId, String);
    check(postAttributes, {
      title: String,
      url: String
    });

    var errors = validatePost(postAttributes);
    if (errors.title || errors.url)
      throw new Meteor.Error('invalid-post', "You must set a title and URL for your post");

    var postWithSameLink = Posts.findOne({url: postAttributes.url});
    if (postWithSameLink) {
      return {
        postExists: true,
        _id: postWithSameLink._id
      }
    }

    var user = Meteor.user();
    var post = _.extend(postAttributes, {
      userId: user._id,
      author: user.username,
      submitted: new Date()
    });

    var postId = Posts.insert(post);

    return {
      _id: postId
    };
  }
});
~~~
<%= caption "lib/collections/posts.js" %>
<%= highlight "9~11" %>

De nuevo, los usuarios no deberían nunca ver este mensaje “You must set a title and URL for your post”. Sólo se mostrará si alguien quiere saltarse los controles que hemos dispuesto concienzudamente, y usa la consola del navegador.

Para probarlo, abre una consola del navegador y prueba a enviar un post sin URL:

~~~js
Meteor.call('postInsert', {url: '', title: 'No URL here!'});
~~~

Si hemos hecho bien nuestro trabajo, obtendrás un montón de código extraño junto con un mensaje “You must set a title and URL for your post”.

<%= commit "9-4", "Validar el contenido de la post al enviar." %>

### Validación al editar

Pare redondear las cosas, aplicaremos la misma validación a nuestro formulario de *edición* de posts. El código es muy similar. Primero, la plantilla:

~~~html
<template name="postEdit">
  <form class="main form page">
    <div class="form-group {{errorClass 'url'}}">
      <label class="control-label" for="url">URL</label>
      <div class="controls">
          <input name="url" id="url" type="text" value="{{url}}" placeholder="Your URL" class="form-control"/>
          <span class="help-block">{{errorMessage 'url'}}</span>
      </div>
    </div>
    <div class="form-group {{errorClass 'title'}}">
      <label class="control-label" for="title">Title</label>
      <div class="controls">
          <input name="title" id="title" type="text" value="{{title}}" placeholder="Name your post" class="form-control"/>
          <span class="help-block">{{errorMessage 'title'}}</span>
      </div>
    </div>
    <input type="submit" value="Submit" class="btn btn-primary submit"/>
    <hr/>
    <a class="btn btn-danger delete" href="#">Delete post</a>
  </form>
</template>
~~~
<%= caption "client/templates/posts/post_edit.html" %>
<%= highlight "3,7,10,14" %>

Luego los ayudantes de plantilla:

~~~js
Template.postEdit.onCreated(function() {
  Session.set('postEditErrors', {});
});

Template.postEdit.helpers({
  errorMessage: function(field) {
    return Session.get('postEditErrors')[field];
  },
  errorClass: function (field) {
    return !!Session.get('postEditErrors')[field] ? 'has-error' : '';
  }
});

Template.postEdit.events({
  'submit form': function(e) {
    e.preventDefault();
    
    var currentPostId = this._id;
    
    var postProperties = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    }
    
    var errors = validatePost(postProperties);
    if (errors.title || errors.url)
      return Session.set('postEditErrors', errors);
    
    Posts.update(currentPostId, {$set: postProperties}, function(error) {
      if (error) {
        // display the error to the user
        throwError(error.reason);
      } else {
        Router.go('postPage', {_id: currentPostId});
      }
    });
  },
  
  'click .delete': function(e) {
    e.preventDefault();
    
    if (confirm("Delete this post?")) {
      var currentPostId = this._id;
      Posts.remove(currentPostId);
      Router.go('postsList');
    }
  }
});
~~~
<%= caption "client/templates/posts/post_edit.js" %>
<%= highlight "1~12,25~27" %>

Tal y como hicimos en el formulario de envío de posts, queremos validar nuestros posts en el servidor. Excepto que recordarás que no estamos usando un método para editar los posts, si no una llamada `update` directamente desde el lado cliente.

Esto significa que tenemos que añadir una nueva regla `deny`:

~~~js
//...

Posts.deny({
  update: function(userId, post, fieldNames, modifier) {
    var errors = validatePost(modifier.$set);
    return errors.title || errors.url;
  }
});

//...
~~~
<%= caption "lib/collections/posts.js" %>
<%= highlight "3~8" %>

Fíjate que el argumento `post` se refiere al post *existente*. En este caso, queremos validar la *actualización*, que es por lo que estamos llamando a `validatePost` con el contenido del modificador de la propiedad `$set` (como en `Posts.update({$set: {title: ..., url: ...}})`).

Esto funciona porque `modifier.$set` contiene las mismas dos propiedades `title` y `url` que el objeto `post`. Por supuesto, esto quiere decir que cualquier actualización parcial que afecte solo a `title` o `url` fallará, pero en la práctica no debería ser una complicación.

Te habrás dado cuenta de que esta es nuestra segunda llamada `deny`. Cuando añadimos múltiples llamadas `deny`, la operación fallará si uno de ellos devuelve `true`. En este caso, esto significa que el `update` solo será satisfactorio si estamos modificando el `title` y la `url`, y ninguna de ellas esté vacía.

<%= commit "9-5", "Validar el contenido del post al editar." %>