Errores

9

Porcentaje completado

En este capítulo:

  • Crearemos un mecanismo mejorado para mostrar errores y mensajes.
  • Implementaremos validaciones más estrictas
  • Mostraremos errores en línea para los formularios.
  • 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 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):

    // Local (client-only) collection
    Errors = new Mongo.Collection(null);
    
    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.

    throwError = function(message) {
      Errors.insert({message: message});
    };
    
    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:

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

    Ahora vamos a crear la plantilla de error en errors.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>
    
    client/templates/includes/errors.html

    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.

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

    Template.errors.helpers({
      errors: function() {
        return Errors.find();
      }
    });
    
    client/templates/includes/errors.js

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

    throwError("I'm an error!");
    
    Probando mensajes de error.
    Probando mensajes de error.

    Commit 9-1

    Mostrando errores.

    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).

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

    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:

    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});
        });
      }
    });
    
    client/templates/posts/post_submit.js

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

    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});
          }
        });
      },
      //...
    });
    
    client/templates/posts/post_edit.js

    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:

    Disparando un error
    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:

    @keyframes fadeOut {
      0% {opacity: 0;}
      10% {opacity: 1;}
      90% {opacity: 1;}
      100% {opacity: 0;}
    }
    
    //...
    
    .alert {
      animation: fadeOut 2700ms ease-in 0s 1 forwards;
      //...
    }
    
    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.

    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.

    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:

    Stack overflow.
    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).

    Template.errors.helpers({
      errors: function() {
        return Errors.find();
      }
    });
    
    Template.error.onRendered(function() {
      var error = this.data;
      Meteor.setTimeout(function () {
        Errors.remove(error._id);
      }, 3000);
    });
    
    client/templates/includes/errors.js

    Commit 9-3

    Limpiar errores después de 3 segundos.

    La llamada a 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:

    <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>
    
    client/templates/posts/post_submit.html

    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.

    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' : '';
      }
    });
    
    //...
    
    client/templates/posts/post_submit.js

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

    Session.set('postSubmitErrors', {title: 'Warning! Intruder detected. Now releasing robo-dogs.'});
    
    Consola del navegador
    ¡Alerta roja! ¡Alerta roja!
    ¡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):

    //...
    
    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;
    }
    
    //...
    
    lib/collections/posts.js

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

    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});
        });
      }
    });
    
    client/templates/posts/post_submit.js

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

    Capturando errores.
    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:

    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
        };
      }
    });
    
    lib/collections/posts.js

    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:

    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:

    <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>
    
    client/templates/posts/post_edit.html

    Luego los ayudantes de plantilla:

    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');
        }
      }
    });
    
    client/templates/posts/post_edit.js

    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:

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

    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.