Desarrollando mmmelon — Comentarios

Este es el primero de los muchos post que espero escribir sobre el trabajo que hacemos en mmmelon. No voy a hablar de productividad, trabajo en equipo… para eso tenéis nuestro blog oficial. Voy a intentar ofrecer una perspectiva más personal y técnica sobre los pasos que vamos dando en el desarrollo.

En este primer post he decidido hablar de los comentarios ya que es justo la funcionalidad que estamos ultimando ahora.

Puede que en este momento pienses:

Yo que soy usuario pro de mmmelon se que ya tenía comentarios desde el principio

Efectivamente mmmelon cuenta con sistema de comentarios desde el primer día, ya que lo consideramos uno de los pilares para comunicarse en equipo, pero hoy voy a hablar del reciente refactor de esta parte y de las nuevas funcionalidades que lanzaremos muy pronto.

Voy a intentar seguir una misma estructura siempre en estos posts:

- Requisitos
- Desarrollo
- Problemas

Requisitos

En este caso los requisitos eran dos:

- Solucionar varios errores relacionados con la inclusión de metadatos de una url en el comentario
- Añadir entre los comentarios actividad al subir un archivo

La segunda es una funcionalidad pensada desde hace tiempo pero que no ha entrado en desarrollo hasta hace unos días.

Los comentarios son un medio de comunicación asociado a una tarea concreta y con el uso hemos visto que muchos de esos comentarios son: “Ya te he subido el archivo x”, “Te dejo subido el diseño”… Nuestro objetivo en mmmelon es romper barreras en la comunicación y este tipo de comentarios solo añaden contenido superfluo.

La idea es sencilla: cuando alguien sube un archivo ese “evento” aparece entre los comentarios. Con algo tan sencillo eliminas la necesidad de que el usuario escriba un comentario que además no tiene el link al archivo. Este “comentario automático” sí contiene toda la información del archivo y nos permite descargarlo directamente. El resultado es este:

Desarrollo

Como programadores debe ocurrir que el código pasado nos parezca horrible. Es un indicador de progreso, de que estamos mejorando, y lo que hace meses nos parecía bien ahora es horrible o mejorable como mínimo.

En este caso los comentarios son parte de los inicios de mmmelon y desde mi punto de vista tenían varios problemas aún sin resolver:

- Variables de sesión para muchas funcionalidades
- Duplicidades entre los comentarios de la home, comentarios en tarea y respuestas
- Funcionalidad de obtener los metadatos para una url e incluirlos en el comentario completamente rota
- Más variables de sesión para gestión de inputs

Una vez echada la bronca al yo del pasado el siguiente paso era ver cómo resolver esto. No me gusta tocar algo sin dejarlo mejor que como estaba, creo que es una sana costumbre, y precisamente hace solo una semana había descubierto Flow Components y ya los había utilizado en otras partes con muy buenos resultados solucionando justo muchos de los problemas enumerados.

¿Conclusión? Debía pasar todo el código cliente de comentarios a flow components y además hacerlo bien, evitando parches o cosas a medias.

El resumen tras un par de días de desarrollo es:

  • Mi amor por flow components sigue vivo
  • Arunoda Susiripala no abandones meteor nunca
  • 0 variables de sesión para los comentarios
  • Pasar de 709 -> 451 líneas de código

¿Cómo?

Mixins de flow components

Con ellos puedes separar funcionalidades compartidas por distintos componentes y luego hacer que cada componente implemente distintos mixins. Por ejemplo: en mmmelon tenemos dos input de comentario, uno para comentario nuevo y otro de respuesta. Ambos tienen un mixin común que implementa la funcionalidad de parsear urls, mostrar los metadatos, método para crear comentario… Esto permite que el código que diferencia a esos componentes sea mínimo. Lo mismo ocurre con los 3 tipos de comentario (home, tarea y respuesta) que tienen mucha de su funcionalidad compartida a través de otro mixin.

Acciones como parámetros

Siempre resulta complicado comunicar un template hijo con el padre y muchas veces se recurre a soluciones, digamos, “poco elegantes”, variables de sesión o directamente chapuzas. En este caso el despreocupado yo pasado estaba en un punto intermedio entre las dos primeras.

Uno de los problemas era el siguiente: en mmmelon el hilo de una conversación solo tiene un nivel, crear respuestas a respuestas cada vez con más indentado solo lleva a confusión y por lo tanto al pulsar el botón de reply sobre una respuesta que ya existe la caja que aparece es controlada por el comentario raíz, solo que incluye al inicio del comentario una mención (@usuario). Es decir, el template reply tiene que hacer que el template comment (padre) muestre el template leaveReply.

¡Ya lo tengo! Puedo utilizar una variable de sesión que muestra/oculta ese leaveReply y la modifico desde donde haga falta. De esta forma el hijo puede hacer que comment muestre leaveReply. ¡Resuelto!
¡Yo me llamo Ralph!

Creo que la imagen deja claro que esa no es la solución. Cada comentario se pinta dentro de un #each, utilizando una variable de sesión provocarías que todos los comentarios muestren u oculten su caja de leaveReply.

¡No pasa nada! ¡Una variable de sesión por comentario con el id de cada uno!
No amigo no

Eso funciona pero puedes acabar con una cantidad de variables de sesión… mejor ni pensarlo.

La solución más sencilla es pasar al template reply una función que se encargue a nivel de comment de mostrar u ocultar ese otro template. Flow components hace esto tremendamente sencillo y reutilizamos la “acción” declarada en el mixin mencionado antes para que tanto comment como reply puedan llamarla.

Con el refactor de los comentarios ya terminado añadir la actividad al subir un archivo ha sido bastante sencillo. Template distinto cuando el comentario contiene campo file. Este template no utiliza el mixin de comentario y tiene 3 states propios.

Problemas

Solo he dejado un problema sin resolver. Dentro de un #each no he encontrado solución para evitar que cuando un documento se actualiza se vuelva a pintar el template entero. Es decir, en un caso como:

{{#each comments}}
{{ > comment comment=this}}
{{/each}}

Cuando cambia algo en ese comentario el template queda invalidado y se pinta de nuevo. Es un problema “menor” si no realizas muchos cambios y no tienes animaciones basadas en ui hooks dentro de ese template. En mi caso tenía animaciones y la solución ha sido sacar la animación fuera del template comment pero se que el template comment se elimina y vuelve a pintar cuando algo cambia.

Espero que os guste conocer mis experiencias desarrollando mmmelon.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.