DEV Community: Sergio

Unir diseño con traducción: hasta dónde.

Sergio — Tue, 18 Jul 2023 11:00:31 +0000

En este artículo explicaré por qué probé a introducir a los diseñadores de UI a formar parte de las traducciones, y por qué he llegado a la conclusión de que no es, al menos, el momento de hacer integraciones entre sus herramientas y las de traducción.

Índice

1. De dónde surge la idea
2. Veía potenciales procesos a plantear
3. Entonces, ¿los diseñadores dan de alta las palabras?
4. ¿Puedo integrar mi herramienta de diseño con el TMS?
       4.1. Sólo un idioma en la app de diseño de UI, y todo a texto plano (como toda la vida)
       4.2. Los diseñadores establecen las cadenas de texto, y los programadores las cargan en el TMS.
       4.3. Lo que nos ahorremos en establecer integraciones aquí, lo podremos emplear en otros procesos
5. Conclusión
 

De dónde surge la idea

Los diseñadores son probablemente las personas en una empresa que más conocen el valor de un Design System junto con los programadores front-end. Normalmente en estos Design System hay un apartado que trata cosas como el tono de voz y la personalidad.

¿Cuántos de vosotros no estáis hasta las 👃 de que diferentes personas os estén diciendo de cambiar los textos/copies de la interfaz o mensajes? 😀

Bueno, pues estas reglas del Design System establecen cómo han de ser los copies para mejorar la calidad y reducir la fricción de los procesos.

Entonces pensé: en las operaciones de diseño habrá que hacer algo.

Veía potenciales procesos a plantear

Unas herramientas claves en esto son las Translations Management Systems/Software o TMS, que permiten tener un punto central donde gestionar prácticamente todo el ciclo de vida de las traducciones.

Operaciones ligadas a las traducciones. Fuente: Phrase

Otro punto importante es tener un idioma base para todos los procesos del proyecto, ya que las cadenas de texto necesitan de un idioma base para ser traducidas al resto (luego puedes crear otros flujos de traducción para optimizar costes pero no viene al tema).

Veía que los diseñadores suelen tener un montón de páginas en herramientas como Figma, exponiendo las mismas "vistas"/"componentes" (V/C en adelante) y cuando se cambiaba alguna palabra, otras V/C quedaban desactualizadas. Luego, si había que hacer una revisión para ver que todo estaba bien, había que estar preguntando: "oye, ¿es este el copy o es este otro?"

Imagina a alguien que acaba de entrar, que no se entera de la película, viendo como hay textos distintos en la aplicación y, que en muchas ocasiones, te ahorras preguntar ya que el coste de desconcentrar a otras personas por algo así no compensa. Pero esa imagen de desorden y falta de integridad está en la calidad de proyecto y de la app. Esta problemática se encuentra más en proyectos en los que no hay un Design System.

Ejemplo de cómo se pueden crear falta de integridad en la herramienta de diseño y en las apps finales

Por eso pensé que podría haber alguna manera de que los diseñadores pudieran vincular las cadenas de texto del TMS con las que hay en los mocks/prototipos (llámese como desee) para que se viera exactamente igual en todas las V/C y también en la app, que de ser multiplataforma, entonces en todas las apps.

Esto también permitiría ver los mocks/prototipos en distintos idiomas (conforme vayan traduciéndose en el TMS), así como escalar el trabajo si se utiliza una arquitectura de componentes.

De una manera simple de dibujar, el escenario quedaría en algo tal que así (perdonad el serif del número 1 😅):

La función del TMS en esta operativa a grosso modo

La duda que te puede saltar ahora es: ¿dónde dan de alta esas traducciones? ¿En Figma, en el TMS? ¿Acaso lo tienen que hacer ellos?
 

Entonces, ¿los diseñadores dan de alta las palabras?

En resumidas cuentas: sí. Creo que los diseñadores darán de alta el 99% de copies y serán responsables de optimizar el uso de estos.

Pero claro, ¿dónde los dan de alta? ¿En Figma, o en el TMS? ¿Cómo hacen cambios y dónde?

Pues para responder a eso, hay que ver primero la escena actual de integraciones.

¿Puedo integrar mi herramienta de diseño con el TMS?

Cómo hay pocos TMS (ironía), y encima no hay todavía un estándar común en estos procesos, las integraciones terminan dejando dudas. Algunas incluso ni funcionan.

Una pequeña demostración del listado de integraciones que he probado para Figma

He revisado más de 10 TMS y más de 30 integraciones y la conclusión es la que planteo en los siguientes puntos:

Sólo un idioma en la app de diseño de UI, y todo a texto plano (como toda la vida)

No hace falta más. Los mocks tienen que servir para que los programadores y personal de producto cuenten con una fuente de información que les permita ver cómo tiene que quedar un desarrollo.

Entre las complicaciones, nos encontramos con cómo introducir contenido dinámico (título de películas a ejemplo del mock), cómo introducir texto con placeholders (variables), plurales, ordinales, cómo mantener la app de UI rápida y ligera, cómo mantener el versionado de los diseños y cómo mantener actualizados ciertos cambios de manera bidireccional.

Se que cuesta quitar azúcar, pero el proyecto irá perfectamente aun sin disponer mocks en múltiples idiomas. Esto reducirá muchísimo la toma de decisiones que hay que hacer y por eso, este artículo será más breve 😎

Los diseñadores establecen las cadenas de texto, y los programadores las cargan en el TMS.

Los diseñadores dictaminarán las palabras en texto plano, como han hecho siempre, pero también tendrán que ser responsables de su reutilización.

Así que: colleja al que utilice "Atrás" cuando ya existe un "Volver atrás" en toda la app.

Los diseñadores tendrán un glosario de términos, donde existirán términos de tipo "actions". Serán responsables de reutilizarlos.

Y los programadores, utilizando herramientas de CI y frameworks de i18n, serán los que carguen esas cadenas de texto en el TMS para que los traductores dispongan de trabajo.

Con esta reglas básicas, los desarrolladores también podrán añadir cadenas de texto que los diseñadores no hayan tenido en cuenta por cualquier motivo. Cosas tales como plurales o asuntos relacionados con ICU. Así mismo, a ser posible, los diseñadores reflejarán estas cadenas de texto faltantes una vez sean conscientes.

Lo que nos ahorremos en establecer integraciones aquí, lo podremos emplear en otros procesos

Aún nos falta meter otras cosas en este puzzle, como por ejemplo el versionado en Figma, el versionado en el TMS, Storybooks, etc. donde sí que podemos hacer cosas muy potentes.

Conclusión

En referencia a este aspecto de la i18n y la fase de diseño, estableceremos unas normas básicas que no requerirán de integraciones programáticas y podremos lograr integrar i18n con mucha efectividad.

Espero que te haya sido de utilidad.

https://softwers.dev

BDD automated-testing con Gherkin y Jest en Node.js 🦄

Sergio — Sun, 08 Dec 2019 02:30:24 +0000

Creo que los test en una aplicación son la mejor documentación que podemos crear. No solo son pruebas, también pueden narrar el comportamiento de la aplicación y sus restricciones.

Además, es un buen punto donde las necesidades de negocio y el QA se pueden acercar al nivel de desarrollo.

Pero gestionar el testing de una aplicación no es tarea fácil, porque las necesidades se transforman en el tiempo y se nos requiere mantener toda la estructura de tests que tenemos desarrollada. Por si fuera poco, también tenemos que mantener la documentación, arquitectura de la aplicación, etc.

Es por eso que la automatización se vuelve un enclave vital para mantener nuestro proyecto lo más ágil (sí, agile en Español) posible.

[Image Source](https://blog.testlodge.com/tdd-vs-bdd)

Aquí es donde vamos a entrar en juego.

Caso en un entorno Agile

Todo comienza por una necesidad.

Vamos a suponer que formamos parte de un equipo de 3 desarrolladores emprendedores los cuales nos hemos repartido roles en el de desarrollo de software. Nosotros (usted lector y yo) nos vamos a encargar de las soluciones más abstractas del proyecto.

Uno de los compañeros quiere que desarrollemos la implementación de una estructura de datos de una Lista Enlazada. Él no se quiere encargar de dicha abstracción, por que está dedicado su tiempo a concreciones de más alto nivel para el negocio. Sin embargo, esta necesidad es importante porque un error en la implementación podría suponer un gran coste y un sin fin de problemas. Además pensamos utilizarla en varias partes del proyecto.

Realmente él habría hecho el mismo proceso de Descubrimiento, Formulación, Automatización que vamos a narrar en este artículo pero con un lenguaje más de producto y no tanto de ciencias de la computación.

Para el que no lo sepa, una Lista Enlazada tiene la siguiente estructura. Aquí podrás encontrar más información.

Forma visual de una Lista Enlazada

Quien se dedique a implementar algoritmos y estructuras de datos sabrá que es fácil colarse por algún lado. Es importante sentarse previamente a definir cómo funcionará, aunque normalmente todos vamos corriendo al código 😌. En este caso, la Lista Enlazada ya está más que definida porque es muy popular y muy sencilla.

Practicamos un poco de BDD y nos sentamos con nuestro compañero emprendedor para desarrollar la historia de usuario.

Descubrimiento: lo que podría hacer

Nos pide que necesita la implementación de la Lista Enlazada.

Como desarrollador de componentes de la aplicación, quiero crear una lista enlaza con la secuencia de teclas que pulsamos en el teclado para poder implementar la lógica de un historial de comandos.

Sería algo parecido al historial de comandos de Photoshop

Conversando con nuestro compañero, descubrimos que para lo que necesita ahora, con la siguiente serie de requerimientos podemos empezar:

Requerimientos

Poder instanciar una lista

La lista estará vacía por defecto

La lista tendrá una longitud

La lista ha de tener un HEAD y un TAIL

Poder añadir elementos al final de la lista

Los elementos guardarán un puntero al siguiente elemento

Formulación: Qué debe de hacer

Sabemos lo que nuestro cliente quiere, ahora vamos a escribir los requerimientos en lenguaje Gherkin para sacar juguito a lo que vamos a ver después 🧃.

Gherkin es un Domain-specific language (DSL) / sintáxis que permite definir muy explícitamente el comportamiento de una Feature y los criterios de aceptación. Se puede utilizar para todos los niveles de testing sin restricción, dado que el dominio dará el contexto.

El objetivo de este artículo no es explicar o entrar en detalle sobre Gherkin, pero si tienes algun comentario de mejora o quieres que profundice en más detalle, házlo saber en los comentarios ✍.

Tendremos que hacer un ejercicio por desarrollar los escenarios en base a la información que hemos extraído en el proceso de Descubrimiento previo.

// file 'lib/data-structures/features/singly-linked-list.feature'
Feature: Singly Linked List

  Scenario: Instancing a list
    Given no instance
    When instancing a new Singly Linked List
    Then initial head must be null
    And initial tail must be null
    And length must be 0

  Scenario: Pushing a value on a empty list
    Given an Empty Singly Linked List with 0 nodes
    When pushing 'First Node' as node value
    Then head value becomes 'First Node'
    And tail value becomes 'First Node'
    And the list length becomes 1

  Scenario: Pushing values on a list with a single node
    Given a Singly Linked List with a single node as 'First Node' as value
    When pushing the following values
    | NodeValue   |
    | Second Node |
    | Third Node  |
    Then list length gets incremented to 3
    And tail value becomes 'Third Node'
    But head value still equals to 'First Node'

Opcionalmente le pasamos dicho fichero al compañero para que nos compruebe que hemos entendido correctamente sus necesidades. Si hubiese sido un cliente sin habilidades técnicas también sería capaz de entender este lenguaje, y ese es unos de los principios y beneficios de Gherkin.

Cuando uses Gherkin, describe el comportamiento requerido, no el cómo.

Escribir este tipo de textos no es tarea fácil al principio. No obstante es una disciplina que hay que entrenar y que aumentará la calidad de tus entregas y tu pensamiento como desarrollador. Existen buenas y malas prácticas.

Sufre el dolor de la disciplina o sufre el dolor del arrepentimiento.

Automatización: Qué es lo que realmente hace

Aquí viene lo sexy 😏. El principal coste que tiene trabajar con Gherkin es que hay que mantener dos cosas: la definición de la feature y los tests.

Pero amigo mio, vamos a hacer que mantener las dos cosas sea muy liviano, porque definiones y tests estarán enlazados explícitamente a través de jest + jest-cucumber.

Instalemos ambos paquetes

npm i -D jest jest-cucumber

La conexión entre los tests y los ficheros de definición de .feature es bidireccional y muy práctica.

Cuando hagamos un mínimo cambio en el fichero singly-linked-list.feature, el fichero singly-linked-list.steps.js fallará 🚨 para avisarnos de que hay adaptaciones por hacer. Sólo así lograremos lo que se denomina una Documentacion viva real.

Hay que entender que si el fichero singly-linked-list.feature cambia, es porque han habido cambios de negocio. De haber habido cambios en el negocio, nunca estará de más que queden explícitos. Esto lo hacemos a través de dicho fichero. Esto permitirá que el software escale mucho más, sobretodo con la incorporación de nuevas personas al equipo.

Si recién te incorporas a un proyecto, te darás cuenta que hacer TDD puede ser casi imposible. Con la ayuda semántica de los ficheros .feature a través de BDD este proceso se hace mucho más armonioso.

Por otra parte, si el título de alguno de los tests no es exacto a la definición, también fallará. Vamos a poner esto a prueba.

Vamos a crear el siguiente steps test incompleto y vamos a cargar la .feature a través de la función loadFeature():

// file 'lib/data-structures/features/steps/singly-linked-list.steps.js'
const { loadFeature, defineFeature } = require('jest-cucumber');
const { SinglyLinkedList } = require('./SinglyLinkedList');

const feature = loadFeature('./SinglyLinkedList.feature', { loadRelativePath: true, errors: true });

defineFeature(feature, test => {
    test('Instancing a list', ({ given, when, then, and }) => {

        let list;

        given('no instance', () => {
            expect(list).toBeUndefined;
        });

        when('instancing a new Singly Linked List', () => {
            list = new SinglyLinkedList();
        });

        then('initial head must be null', () => {
            expect(list.head).toBe(null);
        });
        and('initial tail must be null', () => {
            expect(list.tail).toBe(null);
        });
        and('length must be 0', () => {
            expect(list.length).toBe(0);
        });
    });

    test('Pushing a value on a empty list', ({ given, when, then, and }) => {

        let list;

        given(/^an Empty Singly Linked List with (.*) nodes$/, (arg0) => {
            list = new SinglyLinkedList();

            expect(list.length).toBe(Number.parseInt(arg0));
        });

        when(/^pushing (.*) as node value$/, (arg0) => {
            list.push(arg0);
        });

        then(/^head value becomes (.*)$/, (arg0) => {
            expect(list.head.value).toBe(arg0);
        });
        and(/^tail value becomes (.*)$/, (arg0) => {
            expect(list.tail.value).toBe(arg0);
        });
        and(/^the list length becomes (.*)$/, (arg0) => {
            expect(list.length).toBe(Number.parseInt(arg0));
        });
    });
});

Ahora corremos Jest para que compruebe los test y obtendríamos el siguiente resultado:

$ npx jest
 PASS  19. Singled Linked List/SinglyLinkedList.steps.js  Singly Linked List
    √ Instancing a list (5ms)
    √ Pushing a value on a empty list (1ms)
    √ Pushing values on a list with a single node (1ms)

 FAIL  19. Singled Linked List/SinglyLinkedList-demo.steps.js
  Singly Linked List
    × encountered a declaration exception (9ms)

  ● Singly Linked List › encountered a declaration exception

Feature file has a scenario titled "Pushing values on a list with a single node", but no match found in step definitions. Try adding the following code:

test('Pushing values on a list with a single node', ({ given, when, then, and, but }) => {
  given('a Singly Linked List with a single node as \'First Node\' as value', () => {

   });

    when('pushing the following values', (table) => {

    });

    then(/^list length gets incremented to (.*)$/, (arg0) => {

    });

    and('tail value becomes \'Third Node\'', () => {

    });

    but('head value still equals to \'First Node\'', () => {

    });
});

Como has podido observar, falta el Scenario: Pushing values on a list with a single node y Jest nos está regalando un precioso copy-paste con el que podremos salir del apuro y ahorrar tiempo. Es una plantilla que se puede mejorar si así lo deseamos; vamos a desarrollar la implementación y hacer que los Third Node y First Node se pasen como argumentos para que el test sea más explícito. El fichero final quedará así:

// file 'lib/data-structures/features/steps/singly-linked-list.steps.js'
    ...
    test('Pushing values on a list with a single node', ({ given, when, then, and, but }) => {

        let list;

        given(/^a Singly Linked List with a single node as '(.*)' as value$/, (arg0) => {
            list = new SinglyLinkedList();
            list.push(arg0);

            expect(list.length).toBe(1);
        });

        when('pushing the following values', (table) => {
            table.forEach((row) => {
                list.push(row.NodeValue);
            });
        });

        then(/^list length gets incremented to (.*)$/, (arg0) => {
            expect(list.length).toBe(Number.parseInt(arg0));
        });
        // Utilizo Regex para determinar qué valor será pasado a través de arg0
        and(/^tail value becomes '(.*)'$/, (arg0) => {
            expect(list.tail.value).toBe(arg0);
        });
        // Utilizo Regex para determinar qué valor será pasado a través de arg0
        but(/^head value still equals to '(.*)'$/, (arg0) => {
            expect(list.head.value).toBe(arg0);
        });
    });
});

Y ahora sí, los tests serán 💚.

Bonus: Extensiones de VSCode

Voy a mencionar dos extensiones que pueden llevar esto a otro nivel de productividad

Jest
VSCode estará corriendo los tests de fondo y permitirá ver en tiempo real el resultado de ellos, así como debuggear de manera individual.

Cucumber (Gherkin) Full Support
Syntax highligther, gherkin-to-test copy paste converter, autocompletion ... Una maravilla.

¿Qué te ha parecido el tema tratado? ¿Te puedo ayudar en algo 🐱‍👓? Muchas gracias por dedicar tu tiempo a leer este artículo y nos vemos en el siguiente.

No olvides exportar los providers en NestJS

Sergio — Mon, 04 Nov 2019 19:40:57 +0000

Si ya conoces NestJS, sabrás que tiene mucha similitud con el framework de front-end Angular. Y no es pura casualidad, dado que NestJS basa gran parte de su arquitectura en librerías del propio Angular.

Si estás comenzando con NestJS, es muy importante que centres energías en aprender cómo funciona el mecanismo de contenedores de Inversión de Control. A su vez, has de saber que se parece bastante al mecanismo de Angular pero no son exactamente iguales.

Por ejemplo, en Angular encontramos un artefacto llamado Component (decorador @component) mientras que en Nest tenemos un artefacto llamado Controller (decorador @controller) que vendría a ser un parecido. Esto se debe a que Nest no tiene que lidiar con temas de view rendering y se centra directamente en el concepto de controlador.

Vamos a hacer un repaso a la interfaz que tienen los decoradores @NgModule y @Module en cada framework —Angular y Nest respectivamente.

// Angular front-end AdminModule
@NgModule({
  declarations: [MyComponent, MyDirective, MyPipe],
  entryComponents: [],
  providers: [MyService], // imported and auto-public for everyone
  imports: [AdminDashboardModule],
  exports: [MyComponent, MyDirective, MyPipe]
})
export default class AdminModule {};

// Nest back-end AdminModule
@Module({
  providers: [MyService, MyRepository, MyFactory, MyHelper],
  controllers: [AdminController],
  imports: [CoreModule],
  exports: [AdminService, MyService/*re-export needed to be public for the enquirer*/]
})
export default class AdminModule {}

Comparando interfaces de los módulos en Angular y Nest

Vamos a hablar en concreto de la propiedad exports en ambos frameworks.

Propiedad exports

En Nest, la propiedad export en un @Module define qué Providers serán expuestos hacia el módulo que lo está importando, también llamado enquirer.

  ...
  providers: [MyService, MyRepository, MyFactory, MyHelper],
  exports: [MyService, MyRepository] // Es necesario exportar para hacerlo público
  ...

Recordemos. Un Provider es aquel elemento que puede ser inyectado como dependencia. Ejemplos de Providers son: servicios, repositorios, factories, helpers, etc.

Mientras que en Angular, la propiedad export en un @NgModule permite listar qué declaraciones—componentes, directivas y pipes— serán expuestas. Todo Provider en la propiedad providers será público y accesible en toda la aplicación bootstrapeada.

  ...
  providers: [MyService], // Serán públicos automáticamente
  ...

Exceptuando aquel módulo que sea Lazy Loaded dado que tendrá su propio lazy loaded injector.

Lo importante de esto es que sepas que en Nest has de especificar qué Providers quieres que sean públicos, ya que por defecto no se exportará ninguno. Esto es una gran diferencia con Angular por que en dicho framework, los Providers son registrados en el módulo root/root injector de toda la aplicación—accesible por lo tanto por todos los módulos—.

El objetivo en Nest es encapsular y aislar 📦 por completo todos los Providers del Module. Pero, si quieres que alguno sea público para quien importe dicho módulo, entonces deberás especificarlo en la propiedad exports.

cats.module.ts 🐈

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';

@Module({
  controllers: [CatsController],
  providers: [CatsService],
  exports: [CatsService] // hago CatsService público!
})
export class CatsModule {}

Espero que este recordatorio y explicación te sean de utilidad en tu proyecto de Nest 🧐.

¿Para qué sirven los métodos .call() y .apply() en JavaScript?

Sergio — Thu, 31 Oct 2019 23:35:09 +0000

He de admitir que el desconocimiento de estos métodos, junto con la sintáxis Class fueron los mayores desencadenantes de querer profundizar más en los fundamentos del lenguaje.

Ahora que te los he mencionado, los comenzarás a ver en todas partes. En realidad ya estaban ahí pero, ¿sabías que hacen?. Pues son muy populares, y mucho más en proyectos ES5 y previos.

Estos métodos forman parte de la base de la programación orientada a objetos de JavaScript, y son cruciales para entender el lenguaje y es una pena que las sintáxis como Class y la keyword new los estén dejando en deshuso. Y digo que es una pena porque son fundamentales y muy importantes en el sistema de herencia prototipal, mientras que los otros son sugar syntax que lo único que hacen es oscurecer el lenguaje.

Antes de comenzar, estos dos métodos están disponibles en el prototype del objeto global Function:

Function.prototype.call
Function.prototype.apply

En este post mostraré ejemplos de uso para que lo entiendas y pongas a prueba.

Métodos call() y apply()

Antes de nada y te voy a ahorrar dolores de cabeza, son exactamente lo mismo. La única diferencia reside en el segundo argumento, donde call() será un listado de argumentos infinito y apply() será un array.

fn.call(this, arg1, arg2, arg3...)
fn.apply(this, [arg1, arg2, arg3...])

Un tip que me ayuda a recodar cuál es cuál es la letra C de call, la cual me recuerda a comas; la a de apply, me recuerda a array

Vamos a un ejemplo con call(). Vamos a crear una pseudoherencia clásica. Se trata de una pseudoherencia clásica porque estamos definiendo la estructura del objeto final, "instancia" de Person.


    
function Human(gender) {
  this.gender = gender;
  this.isAlive = true;
}

function Person(gender, age) {
  // this = {}
  Human.call(this, gender);
  // this = { gender: 'male', isAlive: true }
  this.age = age;
  // this = { gender: 'male', isAlive: true, age: 18 }
  return this;
}

const alberto = Person.call({}, 'male', 18);

console.log(alberto);
process.exit(0)

De manera sencilla, llamamos a la función Person a la cual le pasamos primero un objeto vacío como this, y a continuación los argumentos necesarios por la función.

const alberto = Person.call({}, 'male', 18);

¿Sabes que habría pasado si en vez de poner {} hubiésemos puesto this? Habría pasado lo siguiente:


    
function Human(gender) {
  this.gender = gender;
  this.isAlive = true;
}

function Person(gender, age) {
  // this = global: { ... }
  Human.call(this, gender);
  // this = global: { ..., gender: 'male', isAlive: true }
  this.age = age;
  // this = global: { ..., gender: 'male', isAlive: true, age: 18 }
  return this;
}

const alberto = Person.call(this, 'male', 18);

console.log(alberto);
process.exit(0)

Como puedes ver alberto ahora tiene un montón de propiedades nuevas, y esto se debe a que this en el momento de ser ejecutado con .call hace referencia al objeto window del navegador (o global si estamos en Node como es el caso), y por lo tanto estaríamos pasando como contexto a Person un objeto no deseado.

¿Y si en vez de usar this y call(), llamo a la función directamente?

function Human(gender) {
  this.gender = gender;
  this.isAlive = true;
}

function person(gender, age) {
  // Está recibiendo un this implícito
  // this = global: { ... }
  Human.call(this, gender);
  // this = global: { ..., gender: 'male', isAlive: true }
  this.age = age;
  // this = global: { ..., gender: 'male', isAlive: true, age: 18 }
  return this;
}

const alberto = person('male', 18); // Invocando a la función sin call()
/*
Es lo mismo! La transformación la ejecuta el parser de JS (internals)
  person('male', 18) 'implícito' === 'explícito' person.call(this, 'male', 18)
*/

console.log(alberto);

Sucedería exactamente lo mismo. Podrás observar varias cosas:

No he usado el sandbox porque por lo visto tiene algún mecanismo de seguridad para prevenir esta práctica, dado que supone un riesgo de seguridad. Puedes probarlo en tu navegador o en Node.
He renombrado Person a person, y eso se debe a lo mismo. Se creó una regla para que no se pueda llamar a las funciones directamente si comienzan en letra capital, dado que puede darse el caso de que un desarrollador llame a la función directamente y el this quede referenciado al global/window.

Hay que andarse con ojo a la hora de usar this . Y este es uno de los principales motivos por los que se empiezan a crear nuevos mecanismos como new y Class, para evitar equivocaciones y proveer de una opción más sencilla a los desarrolladores que vienen de lenguajes OOP de clases.

Ahora toca el turno a explicar qué sucede dentro de Person. Retomamos el primer ejemplo. Como puedes ver volvemos a hacer uso de call()^2, pero esta vez en vez de {} usamos la palabra this^3. El this siempre depende del contexto desde el cual se ha ejecutado, y en este caso proviene del call(this)^1 de alberto, que es {}.

(el símbolo > lo uso para que podáis encontrar lo que digo)

function Person(gender, age) {
  // this = {}
  Human.2>call(3>this, gender);
...
const alberto = Person.1>call(1>{}, 'male', 18)

Por lo tanto, continuando la llamada, Human continúa recibiendo el objeto vacío a través del contexto^3 que estamos enviando explícitamente a través de call(this)^2

Aprovecho para mencionar, que es usual decir contexto y referirnos a this, dado que todo this dependerá del contexto desde el que se le llame.

Todo this dependerá del contexto desde el que se le llame. Es por lo tanto una referencia contextual.

function Human(gender) {
  3> // this = {} ( proviene de Human.call(this, gender) )
  this.gender = gender;
  this.isAlive = true;
}

function Person(gender, age) {
  // this = {}
  Human.2>call(2>this, gender);
...
const alberto = Person.1>call(1>{}, 'male', 18)

Ahora viene lo bonito 💕❤🌹🎉en JavaScript existe una técnica llamada Aumentación. Es más fácil leerla y encontrarla como "Augmentation", su variante inglesa.

Lo que está haciendo Human es aumentar el contexto desde el que se le llama. En otras palabras, aumentar el this, añadirle más propiedades (también podrían ser métodos).

Y ahora lo no tan bonito 👺, si queremos aprovechar el potencial de JavaScript, hay que saber cuándo aumentar el contexto. Lo digo porque al final, acaba convirtiéndose en una composición que no aprovecha los prototypes. Digamos que el call() sería como un super(). Pero esto es para otro tema.

Ahora, el contexto tendrá dos propiedades nuevas, que son gender y isAlive. El this que hay en person ha aumentado. Volvemos a aumentar el contexto añadiendo la propiedad age^1. Y finalmente retornamos^2 el contexto aumentado.

function Person(gender, age) {
  ...
  // this = { gender: 'male', isAlive: true }
  this.age = age^1;
  // this = { gender: 'male', isAlive: true, age: 18 }
  return this^2;
}

¿Has entendido las diferencias entre estos dos métodos? ¿Me animo a crear un post con más ejemplos?

Espero tus comentarios y que te haya sido de utilidad.

Mediator design pattern: En dos aplicaciones

Sergio — Tue, 22 Oct 2019 10:54:34 +0000

El patrón de diseño Mediador (Mediator design pattern) es un patrón de comportamiento que permite crear interacciones entre objetos reduciendo un excesivo acoplamiento.

Según definición en Wikipedia

"El patrón mediador define un objeto que encapsula cómo un conjunto de objetos interactúan. Este patrón de diseño está considerado como un patrón de comportamiento debido al hecho de que puede alterar el comportamiento del programa en ejecución."

Esquema básico UML de clases del patrón Mediator

Cuando indagué más sobre este patrón, me encontré con una potente herramienta con la que contar a la hora de solucionar problemas como los que describiré en este artículo.

Ejemplo básico

Un ejemplo sería una sala de chat, donde existen múltiples usuarios que pueden comunicarse públicamente o de manera privada (mensaje privado). La clave está en delegar al Mediador la responsabilidad de los sucesos, desacoplando la interacción entre el resto de instancias.

Un user(User) recibirá la interfaz de Chatroom y podrá ordenarle:

Quiero enviar un mensaje global
Quiero enviar un mensaje a un usuario en concreto
Quiero mutear los mensajes que provean de estos usuarios

Y un chatroom(Chatroom) sabrá procesar estas peticiones. Si esta petición involucra a otras entidades relacionadas con el Mediador, una acción colateral se verá ejecutada de manera invisible al user(User)

// 'chatroom.js'

function Chatroom() {
    this.users = {};
    this.mutes = {};
}

Chatroom.prototype.register = function(user) {
    this.users[user.nickname] = user;
    user.chatroom = this;
}

Chatroom.prototype.unregister = function(user) {
    // this.users ...
}

Chatroom.prototype.deliver = function(message, from, to) {
    if (to && !this.hasMuted(to, from)) { // Comprueba si existe un muteo y envía un mensaje privado
        this.users[to].receive(message, from);
    } else { // Comprueba si existe un muteo y envía un mensaje a todos los usuarios
        for (key in this.users) {
            if (this.users[key] !== from && !this.hasMuted(this.users[key], from)) {
                this.users[key].receive(message, from);
            }
        }
    }
}

Chatroom.prototype.mute = function(receiver, sender) {
    // Prohibe a 'sender' enviar mensajes a 'receiver'
}

Chatroom.prototype.hasMuted = function(receiver, sender) {
    // Comprueba si 'receiver' tiene muteado a 'sender'
    return false;
}

// 'user.js'

function User(nickname) {
    this.nickname = nickname; 
    this.chatroom = undefined;
}

User.prototype.send = function(message, to) {
    this.chatroom.deliver(message, this.nickname, to);
}

User.prototype.receive = function(message, from) {
    console.log(`(${this.nickname}) [${from}]: ${message}`);
}

User.prototype.muteFrom = function(user) {
    // this.chatroom.mute ...
}

User.prototype.disconnect = function() {
    // this.chatroom.unregister ...
}

// 'main.js'

const mainChatroom = new Chatroom();
const offTopicChatroom = new Chatroom();

const sergio = new User('Sergio999');
mainChatroom.register(sergio);

const jose = new User('x0s3');
mainChatroom.register(jose);

const manel = new User('manel');
mainChatroom.register(manel);

sergio.send('Hola a todos');
// (x0s3) [Sergio999]: Hola a todos
// (manel) [Sergio999]: Hola a todos

sergio.send('Hola Manel!', 'manel');
// (manel) [Sergio999]: Hola Manel!

Me gusta imaginar el patrón como un mensajero, y qué mejor ejemplo. El usuario sabe qué acciones puede realizar, pero el mensajero (Mediador) es el que sabe cómo realizarlas. Es como entregarle un bulto con una información y decirle: "Ya sabes lo que toca hacer", o bien preguntarle cualquier cosa que sea capaz de responderte.

En el anterior ejemplo, se intercomunican instancias del mismo tipo (User). Sin embargo podrían ser de cualquier otro tipo, como por ejemplo una torre de control donde pueden comunicarse tanto Aviones, Pilotos, Operarios de tierra, etc...

Aquí todavía no ha llegado Tsunami Democratic

No voy a detallar una implementación de la torre de control, dado que sería muy parecido. Voy a pasar a otro caso de uso muy destacable.

Uso como Workflow de eventos

Otro uso que se le puede dar al patrón Mediator es como desarrollo de un workflow, dado de que se parte del concepto de Mediator como una figura que toma el control de acciones para inter-desacoplar los objetos asociados a él.

En el siguiente ejemplo tomamos VideoProcessorWorkflow como el mediador de los eventos. Sus colleages (elemento en el UML de Mediator Design Pattern) serán instancias de módulos con lógica totalmente encapsulada y aislada a través de cada una de sus interfaces:

// 'videoprocessor.workflow.js'

function VideoProcessorWorkflow(
    video,
    { videoConverter, videoFXApplier, videoUploader },
    opts
) {
    const { emit, on, once } = new EventEmitter();
    // Exposing public members
    this.on = on;
    this.once = once;

    // Defining the workflow. Callback style for the glory
    videoConverter.exec(video, opts.converter).once('video/converted', (err, video => {
        videoFXApplier.exec(video, opts.fx).once('video/fxed', (err, video) => {
            videoUploader.exec(video, opts.upload).once('video/uploaded', (err, link) => {
                // Workflow emits a result event
                emit('videoProcessorWorkflow/completed', link);
            });
        });
    }));
}

VideoProcessorWorkflow será una función constructora que expondrá los métodos .on() y .once() a los que poder añadir handlers.

Por otra parte tenemos features/componentes/modulos que contienen lógica totalmente aislada, pero que podemos utilizar a través de un proceso como el Workflow que acabamos de desarrollar.

// 'modules/index.js'

/**
 * Módulos totalmente desacoplados que emiten eventos
 */

function VideoConverterModule(video, opts) {
    // Implementation
}

function VideoFXApplierModule(video, opts) {
    // Implementation
}

function VideoUploaderModule(video, opts) {
    // Implementation
}

Y finalmente lo que vendría a ser el main(), contenedor principal o controlador que orquesta el workflow y sus dependencias.

// 'main.js'

const video = 'file.avi';

const modules = {
    videoConverter: new VideoConverterModule(),
    videoFXApplier: new VideoFXApplierModule(),
    videoUploader: new VideoUploaderModule()
};

const opts = {
    converter: {
        outputFormat: 'mp4'
    },
    fx: {
        bright: -1
    },
    upload: {
        to: 'youtube',
        description: '...'
    }
};


const videoProcessorWorkflow = new VideoProcessorWorkflow(video, modules, opts);

videoProcessorWorkflow.on('videoProcessorWorkflow/completed', (err, link) => {
    console.log(`Video uploaded to: ${link}`);
    process.exit(0);
});

Con este patrón se podrían seguir creando más Workflows para la digestión de eventos, como por ejemplo sería un VideoProcessorErrorWorkflow que encadene una serie de sucesos a raíz de un error en alguno de los módulos.

Hasta aquí mi aportación del día, espero que te haya sido de utilidad!

What's your thought about pseudoclassical OOP in JS?

Sergio — Sat, 19 Oct 2019 12:19:59 +0000

Hi, I'm a JavaScript beginner and I found pseudoclassical inheritance a bad tool for Javascript, because why going for something pseudo when you can go directly for PHP (for instance)?.

Have you tried to work with pseudoclassical OOP style? Did you worked with pure prototypal inheritance focus? What's your learning about?