DEV Community: gugadev

Making Videoconferences with React and Jitsi!

gugadev — Fri, 16 Oct 2020 22:44:19 +0000

Recently, in our "Product discovery" week, a new functionality raises up: Implement videoconferences inside our webapp. After some research we ended up choosing Jitsi as our tool.

The reason behind this decision were pretty solid:

It's open source
Has support for web and mobile.
Has plugins for frameworks like React, Angular, even Flutter.

So, before all, we needed to make a small PoC to learn about the tool and how we can implement it inside a real world application. If you need more info about Jitsi for web, please check it's repository.

The first thing we need to do is get Jitsi. Currently, there is no an official NPM package available, so, we need to use a script tag as old days. For performance reasons, we don't put the tag inside the HTML, instead, we put it inside the React component.

So, let's hands on it.

First, create a jitsi instance variable state.

Then, we need to add the script when the component mounts.

The loadScript function inserts the script in the body and returns a promise that will be solved after the script loads.

Once jitsi script loaded, we need to instanciate the JitsiMeetExternalAPI class with the following parameters:

host: url where the videoconference call is hosted.
params: all the params available here.

For example, we gonna use roomName and displayName. The first one is the name of the room we want to join and the second the user's mame. Note that both values will be received as props.

The parentNode option tell us which element will be used to insert the Jitsi iframe. So, we provided the div we are returning also.

The last step is save the JitsiMeetExternalAPI instance inside jitsi variable state and a method to destroy it once the component is unmounted.

Then you just need to call the component passing the room and your name to join to a videoconference:

<JitsiMeet roomName="MyRoonName" displayName="Gus" />

And tha'ts all! Pretty simple, right? There is a demo below to check out this code working. You need to create a meet using https://meet.jit.si and connecting using the component 😜

Custom elements in React using a custom JSX pragma

gugadev — Mon, 08 Jul 2019 19:05:16 +0000

You can test a sample project here:

gugadev / react-ce-ubigeo

Example using a custom JSX pragma for enable better tooling for custom elements.

This project was bootstrapped with Create React App.

How to test

Just run the app and drop/choose the ubigeo.txt file that is inside public/ folder.

Background

A element, by definition and spec, cannot accept complex properties like objects or arrays. This is a problem when we want to use these kinds of properties in a React project.

For example, this code doesn't work:

const App = function() {
  const data = { a: true }
  return (
    <div className="my-app"&gt
      <my-comp data={data} /&gt
    </div&gt
  )
}

Because in runtime, the data passed as attribute is converted to string using .toString(). For that reason, if you pass an object, you will ended up receiving an [object Object] (because { a: true }.toString()).

Another problem of using custom elements in JSX is respect to custom…

View on GitHub

Online demo here:

Hey, you can use web components in JSX code anyway.

Yeah, sure. However, there are certain use cases where you cannot use a web component following React guidelines, like passing complex properties such Objects and Arrays and binding custom events. So, what could we do as a workaround for these? Let's see.

Passing objects/arrays to custom elements

There are some options. The easiest way is use JSON.stringify to pass it as a attribute:

const App = () => {
  const data = [
    { x: 50, y: 25 },
    { x: 29, y: 47 }
  ]

  return (
    <h1>My awesome app</h1>
    <x-dataset data={JSON.stringify(data)} />
  )
}

Another option is use a ref to pass the object/array as property instead attribute:

const App = () => {
  const ref = useRef()
  const data = [
    { x: 50, y: 25 },
    { x: 29, y: 47 }
  ]

  useEffect(() => {
    if (ref.current) {
      ref.current.data = data // set the property
    }
  })

  return (
    <h1>My awesome app</h1>
    <x-dataset ref={ref} />
  )
}

Hmm, I prefer the second one. And you?

Binding custom events

This is a very common case when we deal with custom elements. When you need to attach a listener to a custom event, you need to use a ref and use addEventListener yourself.

const App = () => {
  const ref = useRef()
  const data = [
    { x: 50, y: 25 },
    { x: 29, y: 47 }
  ]

  const customEventHandler = function(e) {
    const [realTarget] = e.composedPath()
    const extra = e.detail
    // do something with them
  }

  useEffect(() => {
    if (ref.current) {
      ref.current.data = data // set the property
      ref.current.addEventListener('custom-event', customEventHandler)
    }
  })

  return (
    <h1>My awesome app</h1>
    <x-dataset ref={ref} />
  )
}

Pretty simple, right? But, could we make it even easier? Yeah! using a custom JSX pragma.

Creating a custom JSX pragma

This is not a very simple way when we create the pragma, but, once that, you don't need to add aditional logic like example above. You will ended up using custom elements as any regular React component!

The following code is a fork of jsx-native-events that I've extended adapt it to my needs.

First of all, what is a JSX pragma?

JSX Pragma

Pragma is just the function that transform JSX syntax to JavaScript. The default pragma in React is React.createElement.

So, that you understand this, let's see we have the following sentence:

<button type="submit">
  Hello
</button>

Is transformed to:

React.createElement(
  'button',
  { type: 'submit' },
  'Hello'
)

That's why we need to import React event if we don't use it explicitly!

So, what if we can take control over this transform process? That's exactly a pragma let us. So, let's code it.

So, what we did here? First, we need to get the check if it's an custom element. If is, assign a ref callback. Inside this callback we need to handle the logic.

Once inside the ref callback, get all the custom events and the complex properties. For the first one, the event handler name must start with the prefix onEvent (necessary to not conflict with regular JSX events). For the properties, we are going to check if the type is an object (typeof).

/** Map custom events as objects (must have onEvent prefix) */
const events =
Object
  .entries(props)
  .filter(([k, v]) => k.match(eventPattern))
  .map(([k, v]) => ({ [k]: v }))
/** Get only the complex props (objects and arrays) */
const complexProps =
Object
  .entries(props)
  .filter(([k, v]) => typeof v === 'object')
  .map(([k, v]) => ({ [k]: v }))

At this point, we have both, the custom event handlers and the complex properties. The next step is iterate the event handlers and the complex properties.

for (const event of events) {
  const [key, impl] = Object.entries(event)[0]
  const eventName = toKebabCase(
    key.replace('onEvent', '')
  ).replace('-', '')

  /** Add the listeners Map if not present */
  if (!element[listeners]) {
    element[listeners] = new Map()
  }
  /** If the listener hasn't be attached, attach it */
  if (!element[listeners].has(eventName)) {
    element.addEventListener(eventName, impl)
    /** Save a reference to avoid listening to the same value twice */
    element[listeners].set(eventName, impl)
    delete newProps[key]
  }
}

For each event handler, we need to:

convert the camel case name to kebab case: Eg. onEventToggleAccordion to toggle-accordion.
Add the event handler to the listeners map to remove the listener later.
add the listener to the custom element.

For the properties is pretty similar and simple:

for (const prop of complexProps) {
  const [key, value] = Object.entries(prop)[0]
  delete newProps[key]
  element[key] = value // assign the complex prop as property instead attribute
}

Finally, call the React.createElement function to create our element:

return React.createElement.apply(null, [type, newProps, ...children])

And that's all. Now, just left use it.

Using the custom JSX pragma

There are two ways of using a custom pragma. The first is through the tsconfig.json:

{
  "compilerOptions": {
    "jsx": "react",
    "jsxFactory": "webComponents" // default is "React.createElement"
  }
}

The second one is through a comment at top of the files:

/** @jsx webComponents */

Any of these two options you use need to import our pragma:

import React from 'react'
import webComponents from '../lib/ce-pragma' // our pragma

// our component

Now, you can use your custom elements as any regular React component:

/** @jsx webComponents */
import { SFC } from 'react'
import webComponents from '../lib/ce-pragma'

export default function MyScreen() {
  const handleCustomEvent = function (e) {

  }
  return (
    <div>
      <my-custom-component
        data={[ { a: true} ]}
        onMyCustomEvent={handleCustomEvent}
      />
    </div>
  )
}

Conclusion

Using a custom pragma sounds like a very situable solution for now. Maybe in a short-term future React have better custom elements support. All could be possible in the crazy and big JavaScript ecosystem.

Shadow DOM: eventos, target y bubbling.

gugadev — Mon, 01 Jul 2019 19:51:33 +0000

👉 Para mejor entendimiento del presente artículo, es necesario entender lo que significa bubbling en JavaScript.

La idea detrás del Shadow DOM es el encapsulamiento. No es tan distinto, en lo que a objetivos se refiere, a algunos patrones de diseño y/o técnicas de abstracción.

Cuando hablamos de encapsulamiento generalmente nos referimos a datos e información que deseamos se mantenga en un ambiente protegido, sin poder ser accedida fuera de este. Shadow DOM encapsula datos: DOM Tree, estilos y código JavaScript, pero también encapsula otra cosa: eventos.

Eventos en el Shadow DOM

Los eventos que ocurren dentro del Shadow DOM tienen su ciclo de vida solo dentro de este. Es decir, si un botón dentro de un Shadow DOM dispara un evento 'click', el efecto bubbling taladrará por el árbol DOM hasta llegar al host, el cual es el custom element en sí. Una vez que llega allí, no podrá avanzar hacia fuera (light DOM). Es decir: el host es el techo de un evento. Sin embargo, se nos da una "versión" del evento original, versión que omite partes importantes, como el origen del evento.

Veamos cómo funciona con un ejemplo. En el siguiente ejemplo tenemos un elemento fancy-button, el cual es un custom element que contiene un botón con algunos estilos. Si añadimos un listener para el evento click sobre este elemento y obtenemos el target, obtendremos el elemento mismo.

Pruébalo y abran la consola de CodeSandbox para ver el resultado:

Aquí podemos observar claramente que el bubbling del evento tiene como "techo" al host mismo; por ende, el light DOM está completamente inconsciente de los eventos que se originan allí.

Pero, ¿qué pasa cuando necesitamos acceder al target real?

🚀 Bubbling, `composed` y `composedPath`:

Algunos eventos (que implementan la interfaz Event) tienen una propiedad booleana llamada composed, la cual indica si en el payload del evento se podrá acceder a toda la cadena bubbling del evento incluso fuera del Shadow DOM.

Todos los eventos que son disparados por elementos UI (click, paste, change, etc.) tienen esta propiedad en true por defecto.

Cuando esta propiedad está en true, se armará un array con todos los elementos por los cuales ha burbujeado el evento. Para acceder a dicho array lo hacemos mediante el método composedPath.

Veamos el mismo ejemplo anterior, pero esta vez, accediendo al primer elemento del array que viene a ser el primer elemento en donde se originó el evento. Lo desactivaremos durante 1.5 segundos y luego lo activaremos nuevamente.

Espero hayan encontrado entretenido este tutorial y, sobre todo, que hayan aprendiendo algo nuevo. Si les gustó, no olviden compartir 😉

¡Nos vemos en la próxima!

Entendiendo el hoisting

gugadev — Sun, 07 Apr 2019 18:59:10 +0000

En esta oportunidad, analizaremos un comportamiento que sucede a cada instante cuando programamos en Javascript, pero que no podemos verlo; un concepto abstracto, imperceptible. Algo que pasa "detrás de escenas" y que es parte del lenguaje. Hoy hablaremos de hoisting.

Antes de entender qué es hosting recomiendo leer mi post anterior: This y el contexto de ejecución, ya que necesitaremos entender lo que es un contexto de ejecución.

Analicemos el siguiente código:

var name = 'stuxdev'

whoami() // <- Im stuxdev

function whoami() {
  console.log('Im ', name)
}

Si la función whoami es escrita al final de nuestro código, ¿cómo es que puede invocarse antes de que se defina? ¿Cuál es el sentido de esto?

La respuesta es: el contexto de ejecución y sus fases.

Fases del contexto de ejecución

La creación de un contexto de ejecución se divide en dos fases: creación y ejecución. Veamos en qué consisten estas fases.

Fase de creación

En esta fase ocurren tres cosas importantes:

Se crea el objeto global window.
Se crea el objeto especial this para representar el contexto de ejecución actual.
Se crean espacios en memoria para reservar en memoria las declaraciones de variables y funciones.

Es esta última frase justamente donde se produce lo que conocemos como hoisting. Pero, ¿qué sucede durante el hoisting?

Hosting

Es simplemente un nombre que sirve para identificar el proceso de colocar las declaraciones de variables y funciones en memoria dentro de un contexto de ejecución. Es decir, todas las declaraciones se ponen en memoria en la parte más alta del stack.

Si en un contexto léxico tenemos un código así:

var language = 'English'

changeLanguage()

function changeLanguage() {
  language = 'Spanish'
}

Cuando ocurre el hoisting, en memoria es traducido de la siguiente manera:

var language;

function changeLanguage() {
  language = 'Spanish';
}

changeLanguage();

Aquí nos damos cuenta de un par de cosas interesantes. La primera, es que cuando ocurre el hoisting, solo se mueven las declaraciones de variables, mas no se inicializan:

var language; // <- no hay inicialización

Lo segundo, es que las function statements son puestas enteras, mientras que las function expressions, al ser parte de una declaración de variable, solo se mueve la parte de declaración. Para que se entienda, veamos el siguiente ejemplo:

function foo() { ... }
var bar = function bar() { ... }

Cuando ocurra el hoisting, se convertirá en lo siguiente:

function foo() { ... }
var bar;

Fase de ejecución

En esta fase se lleva a cabo la ejecución del código, sentencia a sentencia. En esta parte es precisamente en donde se identifican en memoria todas las declaraciones de variables y funciones y se les asigna su contenido. En el caso particular de las funciones como asignaciones, en tiempo de ejecución no tendrán un valor hasta que el intérprete llegue a la línea en donde se le asigna un valor.

console.log('¡Soy un ninja JS!')
var sayHi = function sayHi() {
  ...
}

En el hosting será:

var sayHi;
console.log('¡Soy un ninja JS!')

Quiz time!

Veamos un código de ejemplo que nos sirva como ejercicio para poner en práctica lo que se ha tratado a lo largo del artículo.

Teniendo como base este código:

goodMorning()
goodEvening()

function goodMorning() {
  console.log('Buenos días')
}
var goodEvening = function goodEvening () {
  console.log('Buenas noches')
}

👽 ¿Cuál es la salida del código?

🚫¡No se vale usar internet!

Deja la respuesta en los comentarios. Actualizaré el post para explicar la respuesta 😉

⭐ Plus

Si usas Visual Studio Code como editor, puedes instalar Quokka. Es un plugin para ejecutar directamente código JavaScript en tu editor a medida que lo escribes. Muy útil para pruebas rápidas.

JavaScript internals - This y el Contexto de ejecución

gugadev — Sat, 06 Apr 2019 02:52:29 +0000

Cuando empezamos a aprender JavaScript y llegamos a la parte de herencia, instancias y métodos, nos topamos con un villano difícil de vencer. Hablo del misterioso this.

Para explicar esto debemos tener en cuenta un concepto importante: contexto de ejecución.

Contexto de ejecución

Piensa en el contexto de ejecución como en una bolsa. Cada una de estas bolsas se compone de tres cosas:

Lexical Environment
Variable Environment
Objeto this

Lexical y Variable environment es lo mismo (salvo casos excepcionales que no discutiré aquí). Dentro de este, se almacenan dos cosas: una referencia opcional al outer scope y un record o registro que mapea dentro de una tabla los identificadores con sus valores.

Para ilustrar mejor este concepto, imaginemos que tenemos el siguiente código:

var boo = 3
function test() {
  var foo = 1
  var bar = 'a'
  function baz() { ... }
}

Cuando se ejecute, se creará una nueva bolsa, cuyo Lexical environment tendrá la siguiente información:

Elemento	Valor
record	`<record table>`
parent	`<global>`

Identificador	Valor
foo	1
bar	'a'
baz	`<function>`

En este caso, como la función no está dentro de ninguna estructura, parent será el scope global. Si fuese un closure (función dentro de otra), parent sería la función que la contiene. Esto es lo que se conoce como scope chaining y sirve para poder acceder a scopes superiores.

Ententiendo `this`

Hasta ahora, hemos comprendido qué es lo que ocurre cuando ejecutamos una función. Aprendimos que, cuando eso pasa, se crea un contexto de ejecución que contiene un lexical environment y también una referencia a this. Pero, ¿cómo se define el valor de este objeto?

Para entender de dónde toma this su valor, hay que saber que su valor dependerá de cómo es ejecutada la función en donde se encuentra. A continuación, listo algunos de los escenarios más comunes.

Dentro de una función

Cuando la función no es parte del prototipo de una función constructora, el valor de this será igual al objeto window. Nota que esto es así aunque sea un closure:

function a() {
  var c = function c() {
    console.log(this === window) // <- true
  }
  setTimeout(function b() {
    console.log(this === window) // <- true
  })
  c()
  console.log(this === window) // <- true
}

a()

Dentro en un método

Cuando se usa this dentro de un método, el valor de this será equivalente al elemento en el que se ejecuta al método:

const guy = {
  whoami() {
    console.log(this === guy) // <- true
  }
}

guy.whoami()

Dentro de un constructor o método

En este caso, this siempre hará referencia a la instancia:

function Person() {}

Person.prototype.whoami = function() {
  console.log(this instanceof Person)
}

const person = new Person() // instancia
person.whoami() // <- true

Usando bind, call o apply

Algunas veces necesitamos sobreescribir el valor por defecto de this para hacerlo dinámico; es decir, que pueda hacer referencia a distintos contextos que queramos. Para esto, podemos usar bind, call y apply:

function sayHi(age) {
  console.log(`Hello, i'm  ${this.name} and I have ${age} years old`)
}

const john = { name: 'John Doe' }
const jane = { name: 'Jane Doe' }
const josh = { name: 'Josh Smith' }

sayHi.bind(john)(24) // Hello, i'm John Doe and I have 24 years old
sayHi.call(jane, 23) // Hello, i'm Jane Doe and I have 23 years old
sayHi.apply(josh, [25]) // Hello, i'm Josh Smith and I have 25 years old

Si el último ejemplo te pareció extraño, no te preocupes. En un próximo post nos adentraremos a los tres desconocidos de JavaScript: bind, call y apply.

Conclusión

Espero que con este artículo te haya quedado un poco más claro de dónde sale this y cómo funciona. Además, hemos aprendido un poquito acerca del core de JavaScript para entender qué es lo que pasa "detrás de escenas", lo cual es muy importante para la compresión del lenguaje 😉

ES6 Proxies en práctica

gugadev — Tue, 12 Mar 2019 19:33:55 +0000

Con la aparición de ECMAScript 2015 (aka ES6), vino una avalancha de features; unas que ya se venían pidiendo a gritos desconsolados y desgarradores, y otros que fueron gratas sorpresillas, como cuando te encuentras a un viejo amigo mucho tiempo después.

Una de las features -del último grupo descrito- son las relacionadas a la metaprogramación. ¿Qué es eso? No ando muy elocuente hoy, así que vayamos a nuestra infalible amiga, la Wikipedia.

La metaprogramación consiste en escribir programas que escriben o manipulan otros programas (o a sí mismos) como datos, o que hacen en tiempo de compilación parte del trabajo que, de otra forma, se haría en tiempo de ejecución. Esto permite al programador ahorrar tiempo en la producción de código.

Podemos entender por metaprogramación como la capacidad de que un programa manipule otros o a sí mismos tanto en tiempo de compilación como de ejecución. Esta capacidad ha sido añadida a los lenguajes de programación prácticamente desde sus inicios y ahora también la tenemos disponible en el lenguaje bandera de la web: JavaScript.

La metaprogramación en JavaScript se basa en dos features: Proxy y Reflect API. En esta publicación trataremos el primero.

Proxy

Proxy es una nueva API que nos permite interceptar, modificar y extender objetos en tiempo de ejecución. Tan simple como eso; a través de esta API podemos realizar cosas como:

Profiling y logs de depuración.
Intercepción de llamadas a propiedades.
Validaciones "on the fly".

Entre otras muchas.

Proxy es un constructor que acepta dos parámetros: el objeto origen, un objeto que actúa como handler para el objeto origen. Este último contiene métodos que son conocidos como Traps.

Un Trap es un método*que modifica el comportamiento* de alguna parte del objeto. Por ejemplo, el trap get y set interceptan las llamadas a propiedades para obtener y establecer un valor respectivamente, pudiendo colocar lógica antes y durante este proceso.

Puedes ver la lista completa de traps aquí.

Para entender mejor la utilidad de los proxies, hagamos unos pequeños ejercicios.

Ejemplo: logging/profiling

Aún tenemos 17 años, estamos en la flor de nuestra adolescencia, ~~haciendo apología al sexo, a los cigarrillos y al alcohol~~ en plena era de aprendizaje y vivencia de nuevas experiencias. Estamos por cumplir los 18 años ya, y queremos que nuestro programa nos felicite automáticamente al cumplirlos 🎉. Para esto, podemos hacer uso de un Proxy.

No solo podemos hacer logs, como dije en un principio, podemos hacer hasta donde el lenguaje nos limite. Aquí pudimos hacer validaciones para la edad, por ejemplo, si pasa de 100 que nos arroje un error:

if (value < 13 && value > 99) {
  throw new Error('La edad debe ser entre 13 y 99')
} else {
  Reflect.set(target, property, value)
}

Ejemplo: acceso seguro a propiedades

Ejemplo: query array

Ya vimos un ejemplo, con los traps get y set, que son los que más se usan. Para reforzar, vamos a ir un poco más allá y usaremos proxies anidados. Este ejercicio tratará de convertir un array convencional a uno queryable, para usar operadores útiles como el clásico groupBy de SQL.

Para esto, necesitaremos dos parámetros de entrada:

collection: array de objetos el cual extenderemos.
groupKeys: array de strings que representan las propiedades por las cual se va a agrupar (name, category, price, etc.)

Conclusiones

Los Proxy quizás no sea una de las más usadas features de ES6, pero es sin duda, junto con Reflect API, una de las más importantes e interesantes. Su flexibilidad nos permite adoptarla en multitud de casuísticas y lo mejor, es fácil de implementar.

Building Instagram/Whatsapp stories clone using Web Components 🔥

gugadev — Wed, 13 Feb 2019 16:35:46 +0000

gugadev / storify

Instagram/Whatsapp stories clone built on Web Components and Web Animations API. 🔥

wc 🌐 stories

Instagram/Whatsapp stories like built on Web Components and Web Animations API

Demos

Vanilla JS	Angular	React	Vue
Link	Link	Link	Link

Browser support

IE / Edge	Firefox	Chrome	Safari	Opera
IE11, Edge	last 10 versions	last 10 versions	last 10 versions	last 10 versions

📦 Install

npm i @gugadev/wc-stories

💡 What's the prupose of it?

Just fun 🙂. I love learn and code, so, this every time I have free time, pick some crazy idea or got inspiration from another projects and make it. 😋

🦄 Inspiration

When I saw the project of Mohit, react-insta-stories, immediately wanted to know how complicated it would be to do the same thing using Web Components. So, I built this. Thanks, Mohit! 😃

⚙️ How it works?

There are three components working together:

<wc-stories-story>: this component shows a image. The maximun size of an image is the containers…

View on GitHub

Note: the styles of the components are not pasted in this post to focus on the logic. However, you can find them in the Github repo.

🦄 Inspiration

A couple of days ago, I discovered a project called react-insta-stories from Mohit Karekar. I thought it was funny built the same idea but using Web Components instead. So, I pick my computer and started to code. 😉

🛠️ Setup

In any project, the first thing you need to do is set up the development environment. In a regular frontend project, we will end up using Webpack as transpiler and bundler. Also, we will use lit-element to write our Web Components and PostCSS for styling, with some plugins like cssnano.

🛠️ Dev dependencies:

yarn add --dev webpack webpack-cli webpack-dev-server uglifyjs-webpack-plugin html-webpack-plugin clean-webpack-plugin webpack-merge typescript tslint ts-node ts-loader postcss-loader postcss-preset-env cross-env cssnano jest jest-puppeteer puppeteer npm-run-all

⚙️ Runtime dependencies:

yarn add lit-element core-js @types/webpack @types/webpack-dev-server @types/puppeteer @types/node @types/jest @types/jest-environment-puppeteer @types/expect-puppeteer

Our source code must be inside src/ folder. Also, we need to create a demo/ folder and put some images inside it.

Webpack

Let's divide our Webpack configuration into three parts:

webpack.common.ts: provide shared configuration for both environments.
webpack.dev.ts: configuration for development only.
webpack.prod.ts: configuration for production only. Here we've to put some tweaks like bundle optimization.

Let's see those files.

webpack.common.js

import path from 'path'
import CleanWebpackPlugin from 'clean-webpack-plugin'
import webpack from 'webpack'

const configuration: webpack.Configuration = {
  entry: {
    index: './src/index.ts'
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'dist')
  },
  resolve: {
    extensions: [
      '.ts',
      '.js'
    ]
  },
  module: {
    rules: [
      {
        test: /\.(ts|js)?$/,
        use: [
          'ts-loader'
        ],
        exclude: [
          /node_modules\/(?!lit-element)/
        ]
      },
      {
        test: /\.pcss?$/,
        use: [
          'css-loader',
          'postcss-loader'
        ]
      }
    ]
  },
  plugins: [
    new CleanWebpackPlugin(['dist'])
  ]
}

export default configuration

This file contains the basic configuration, like, entry and output settings, rules and a plugin to clean the output folder before each build process.

webpack.dev.js

import webpack from 'webpack'
import merge from 'webpack-merge'
import HtmlWebpackPlugin from 'html-webpack-plugin'
import common from './webpack.common'

const configuration: webpack.Configuration = {
  mode: 'development',
  devtool: 'inline-source-map',
  devServer: {
    contentBase: './demo',
    publicPath: '/',
    compress: true,
    port: 4444
  },
  plugins: [
    new HtmlWebpackPlugin({
      filename: './demo/index.html'
    })
  ]
}

export default merge(common, configuration)

The development configuration only adds the webpack-dev-server settings and one extra plugin to use an HTML file as index.html provided for the development server.

webpack.prod.js

import webpack from 'webpack'
import merge from 'webpack-merge'
import UglifyPlugin from 'uglifyjs-webpack-plugin'
import common from './webpack.common'

const configuration: webpack.Configuration = {
  mode: 'production',
  devtool: 'source-map',
  optimization: {
    minimizer: [
      new UglifyPlugin({
        sourceMap: true,
        uglifyOptions: {
          output: { comments: false }
        }
      })
    ]
  }
}

export default merge(common, configuration)

Finally, our production configuration just adjust some 🚀 optimization options using the uglifyjs-webpack-plugin package.

That's all the webpack configuration. The last step is create some scripts into our package.json to run the development server and generate a ⚙️ production build:

"start": "cross-env TS_NODE_PROJECT=tsconfig.webpack.json webpack-dev-server --config webpack.dev.ts",
"build": "cross-env TS_NODE_PROJECT=tsconfig.webpack.json webpack --config webpack.prod.ts",

PostCSS

We need to create a .postcssrc file at the root of our project with the following content to process correctly our *.pcs files:

{
  "plugins": {
    "postcss-preset-env": {
      "stage": 2,
      "features": {
        "nesting-rules": true
      }
    },
    "cssnano": {}
  }
}

Typescript

And finally, we need to create a tsconfig.json file to configure our Typescript environment:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "allowJs": true,
    "esModuleInterop": true,
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "sourceMap": true,
    "removeComments": true
  },
  "include": [
    "src/"
  ],
  "exclude": [
    "node_modules/"
  ]
}

Aditionally, create a tsconfig.webpack.json file that will be used by ts-node to run Webpack using Typescript:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "esModuleInterop": true
  }
}

🏭 Structure

Let's keep things simple. We'll need to write three components:

container
story
progress bar

The container is where the logic will be written. Here we hold the control of which image should be visible, and which not, also, we need handle the previous and next clicks. The story component is where the images will be shown, and the progress bar component, is where we can visualize the timming for the current image.

📦 The `<story>` component.

This component is simple, it's just contains a div with an img inside it. The image's wrapper is necessary to able the animation.

Let's create a index.ts file under stories/ folder, with the following content:

import {
  LitElement,
  html,
  customElement,
  property
} from 'lit-element'
import styles from './index.pcss'

@customElement('wc-stories-story')
class Story extends LitElement {

  /**
   * @description image absolute or relative url
   */
  @property({ type: String }) src = ''
  /**
   * @description checks if an image is available to show
   */
  @property({ type: Boolean }) visible = false

  render() {
    return html`
      <div class="${this.cssClass}">
        <img src="${this.src}" />
      </div>
      <style>
        ${styles.toString()}
      </style>
    `
  }

  get cssClass() {
    return [
      'stories__container__story',
      this.visible ? 'visible' : ''
    ].join(' ')
  }
}

export { Story }

The anatomy of an Web Component using lit-element is simple. The only mandatory method you need to implement is render. This method must returns the html content that will be shadowed.

This component, accept two properties. The first, is the relative or absolute URL of the image to show (src) and the second one, the flag that notifies the component when it should be shown (visible).

You will realize that each component import it's styles from a standalone .pcss file, containing the PostCSS code. This is possible thanks to postcss-loader and style-loader webpacks loaders.

That's all 🙂 Easy, right? Let's see our next component.

📦 The `<progress>` component

This component is small, but interesting. The responsability of this block is providing an animation for each image. The animation is just a progress bar, ¡using Web Animations API!

import {
  LitElement,
  html,
  property,
  customElement
} from 'lit-element'
import styles from './index.pcss'
/* Array.from polyfill. The provided by Typescript
 * does not work properly on IE11.
 */
import 'core-js/modules/es6.array.from'

@customElement('wc-stories-progress')
class Progress extends LitElement {

  /**
   * @description count of images
   */
  @property({ type: Number }) segments = 0

  /**
   * @description current image index to show
   */
  @property({ type: Number, attribute: 'current' }) currentIndex = 0

  /**
   * @description progress' animation duration
   */
  @property({ type: Number }) duration = 0

  /**
   * @description object that
   * contains the handler for onanimationend event.
   */
  @property({ type: Object }) handler: any = {}

  /**
   * Current animation
   */
  private animation: Animation

  render() {
    const images = Array.from({ length: 5}, (_, i) => i)

    return html`
      ${
        images.map(i => (
          html`
            <section
              class="progress__bar"
              style="width: calc(100% / ${this.segments || 1})"
            >
              <div id="track-${i}" class="bar__track">
              </div>
            </section>
          `
        ))
      }
      <style>
        ${styles.toString()}
      </style>
    `
  }

  /**
   * Called every time this component is updated.
   * An update for this component means that a
   * 'previous' or 'next' was clicked. Because of
   * it, we need to cancel the previous animation
   * in order to run the new one.
   */
  updated() {
    if (this.animation) { this.animation.cancel() }

    const i = this.currentIndex
    const track = this.shadowRoot.querySelector(`#track-${i}`)

    if (track) {
      const animProps: PropertyIndexedKeyframes = {
        width: ['0%', '100%']
      }
      const animOptions: KeyframeAnimationOptions = {
        duration: this.duration
      }
      this.animation = track.animate(animProps, animOptions)
      this.animation.onfinish = this.handler.onAnimationEnd || function () {}
    }
  }
}

export { Progress }

This component has the following properties:

duration: duration of the animation.
segments: image's count.
current: current image (index) to show.
handler: object containing the handler for onanimationend event.

The handler property is a literal object containing a function called onAnimationEnd (you'll see it in the last component). Each time the current animation ends, this funcion is executed on the parent component, updating the current index and showing the next image.

Also, we store the current animation on a variable to ❌ cancel the current animation when need to animate the next bar. Otherwise every animation will be visible all the time.

📦 The `<stories>` component

This is our last component. Here we need to handle the flow of the images to determine which image must be shown.

import {
  LitElement,
  customElement,
  property,
  html
} from 'lit-element'
import styles from './index.pcss'
import { Story } from '../story'
import '../progress'

@customElement('wc-stories')
class WCStories extends LitElement {

  /**
   * @description
   * Total time in view of each image
   */
  @property({ type: Number }) duration = 5000

  /**
   * @description
   * Array of images to show. This must be URLs.
   */
  @property({ type: Array }) images: string[] = []

  /**
   * @NoImplemented
   * @description
   * Effect of transition.
   * @version 0.0.1 Only support for fade effect.
   */
  @property({ type: String }) effect = 'fade'

  /**
   * @description
   * Initial index of image to show at start
   */
  @property({ type: Number }) startAt = 0

  /**
   * @description
   * Enables or disables the shadow of the container
   */
  @property({ type: Boolean }) withShadow = false

  @property({ type: Number }) height = 480

  @property({ type: Number }) width = 320

  /**
   * Handles the animationend event of the
   * <progress> animation variable.
   */
  private handler = {
    onAnimationEnd: () => {
      this.startAt = 
        this.startAt < this.children.length - 1
        ? this.startAt + 1
        : 0
      this.renderNewImage()
    }
  }

  /**
   * When tap on left part of the card,
   * it shows the previous story if any
   */
  goPrevious = () => {
    this.startAt = 
      this.startAt > 0
      ? this.startAt - 1
      : 0
    this.renderNewImage()
  }

  /**
   * When tap on right part of the card,
   * it shows the next story if any, else
   * shows the first one.
   */
  goNext = () => {
    this.startAt = 
      this.startAt < this.children.length - 1
      ? this.startAt + 1
      : 0
    this.renderNewImage()
  }

  render() {
    return html`
      <wc-stories-progress
        segments="${this.images.length}"
        duration="${this.duration}"
        current="${this.startAt}"
        .handler="${this.handler}"
      >
      </wc-stories-progress>
      <section class="touch-panel">
        <div @click="${this.goPrevious}"></div>
        <div @click="${this.goNext}"></div>
      </section>
      <!-- Children -->
      <slot></slot>
      <style>
        ${styles.toString()}
        :host {
          box-shadow: ${
            this.withShadow
            ? '0 14px 28px rgba(0,0,0,0.25), 0 10px 10px rgba(0,0,0,0.22);'
            : 'none;'
          }
          height: ${this.height}px;
          width: ${this.width}px;
        }
      </style>
    `
  }

  firstUpdated() {
    this.renderNewImage()
  }

  /**
   * Iterate over children stories to know
   * which story we need to render.
   */
  renderNewImage() {
    Array.from(this.children).forEach((story: Story, i) => {
      if (story instanceof Story) {
        story.visible = this.startAt === i
      }
    })
  }
}

export { WCStories }

Our main component accepts the initial configuration through some properties:

duration: how much time the image will be visible.
startAt: image to show at start up.
height: self-explanatory.
width: self-explanatory.
withShadow: enables or disables drop shadow.

Also, it has some methods to control the transition flow:

goPrevious: show the previous image.
goNext: show the next image.
renderNewImage: iterate over the stories components and resolve, through a comparation between the index and the startAt property, which image must be shown.

All the stories are the children of this component, placed inside an slot:

<!-- Children -->
<slot></slot>

When the Shadow DOM is built, all the children will be inserted inside the slot.

🚀 Time to run!

Create an index.html file inside a demo/ folder at the project root with the content below:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <!-- Open Sans font -->
  <link href="https://fonts.googleapis.com/css?family=Noto+Sans" rel="preload" as="font">
  <link href="https://fonts.googleapis.com/css?family=Noto+Sans" rel="stylesheet">
  <!-- CSS reset -->
  <link href="https://necolas.github.io/normalize.css/8.0.1/normalize.css" rel="stylesheet">
  <!-- polyfills -->
  <script src="https://unpkg.com/web-animations-js@2.3.1/web-animations.min.js"></script>
  <script src="https://unpkg.com/@webcomponents/webcomponentsjs@2.2.7/custom-elements-es5-adapter.js"></script>
  <script src="https://unpkg.com/@webcomponents/webcomponentsjs@2.2.7/webcomponents-loader.js"></script>
  <!-- our script -->
  <script defer src="index.js"></script>
  <title>WC Stories</title>
  <style>
  .container {
    display: flex;
    justify-content: center;
    padding: 50px;
  }
  </style>
</head>
<body>
  <main class="container">
    <wc-stories height="480" width="320" withShadow>
      <wc-stories-story src="img/01.jpg"></wc-stories-story>
      <wc-stories-story src="img/02.jpg"></wc-stories-story>
      <wc-stories-story src="img/03.jpg"></wc-stories-story>
      <wc-stories-story src="img/04.jpg"></wc-stories-story>
      <wc-stories-story src="img/05.jpg"></wc-stories-story>
    </wc-stories>
  </main>
</body>
</html>

Hold this position and create a folder called img/, inside paste some images. Note that you need to map each of your images as a <wc-stories-story> component. In my case, I have 5 images called 01.jpg, 02.jpg and so on.

Once we did this step, we're ready to start our development server. Run the yarn start command and go to localhost:4444. You will see something like this.

✈️ Bonus: definitive proof

The main goal of Web Components is create reusable UI pieces that works on any web-powered platform, and this, of course, include frontend frameworks. So, let's see how this component works on major frameworks out there: React, Angular and vue.

React

Vue

Angular

Cool! it's works! 😃 🎉

🤔 Conclusion

Advice: learn, adopt, use and write Web Components. You can use it with Vanilla JS or frameworks like above. Are native and standarized, easy to understand and write 🤓, powerful 💪 and have an excellent performance ⚡.

Creando una API con GraphQL y Apollo | Parte III

gugadev — Mon, 28 Jan 2019 20:35:50 +0000

En el tutorial anterior creamos una aplicación Angular y creamos un formulario. Vimos cómo por medio de directivas modularizamos nuestro código y le dimos un aspecto elegante mediante un poco de CSS. Sin embargo, como eso no es suficiente, en esta tercera y última parte de la serie, veremos cómo hacer que nuestra app se comunique con nuestra API GraphQL.

Bien, empecemos. Ya tenemos nuestro formulario, ahora, necesitamos darle alguna funcionalidad. En concreto, nuestra tarea para hoy serán dos cosas:

Añadir validación al email para asegurarnos que no esté en uso.
Registrar al nuevo usuario si el punto anterior fue pasado con éxito.

Antes de empezar: ve hacia src/app/graphql.module.ts y asigna a la variable uri la dirección en donde corre nuestra API, la cual es: http://localhost:3000.

Validando que el email no esté registrado.

Si recuerdas mi tutorial pasado acerca de Reactive Forms, recordarás que hablamos de validadores asíncronos. Estos, tienen la particularidad de ser validaciones que retornan una promesa o una instancia de Observable. Por medio de este tipo de validadores podemos realizar validaciones personalizadas. En este tutorial, veremos cómo realizar una validación personalizada con nuestra API GraphQL.

Creación del servicio

Nuestro primer paso será generar un servicio. Le llamaremos signup:

ng g s signup/

Y agregamos el siguiente método checkForExists:

import { Injectable } from '@angular/core'
import { Apollo } from 'apollo-angular'
import { Observable, Subscriber, Observer } from 'rxjs'
import gql from 'graphql-tag'
import { ApolloQueryResult } from 'apollo-client'
import { User } from '../models/user'

@Injectable({
  providedIn: 'root'
})
export class SignupService {

  constructor(private apollo: Apollo) { }

  /**
   * Search an user by his email address
   * @param email | string user's email who's looking for
   * @returns boolean if the user exists or not
   */
  public checkForExists(email: string): Observable<boolean> {
    return Observable.create((sub: Subscriber<boolean>) => {
      this.apollo.query({
        query: gql`
          query Find($email: String!) {
            user(email: $email) {
              id
            }
          }
        `,
        variables: { email }
      })
      .subscribe((value: ApolloQueryResult<any>) => {
        const found: User | null = value.data.user
        sub.next(found !== null)
        sub.complete()
      })
    })
  }
}

Veámoslo un poco en detalle. Lo primero es inyectar la dependencia de Apollo en nuestro constructor. Esta dependencia nos permitirá hacer las consultas a nuestra API.

Segundo, nuestro método checkForExists recibe un parámetro que es el email. Este método devuelve un Observable que almacenará un booleano. Dentro del Observable.create hacemos uso del método query de Apollo. Este método recibe una propiedad query y una variables opcional. En la propiedad query procedemos a realizar nuestra consulta. Vemos que declaramos una variable en GraphQL llamada $email, a esta variable le vamos a dar un valor en la propiedad variables:

variables: { email }

variable cuyo valor no es nada más que el email recibido por parámetro. Esta consulta devolverá un Observable al cual nos subscribimos para obtener data.user que es en donde estará la respuesta que obtengamos.

Esta consulta buscará un usuario por su email. Si lo encuentra, retornará al usuario, caso contrario, retornará null.

Importación del servicio

Ahora procedemos a importar el servicio en SignupModule:

@NgModule({
  declarations: [
    SignupComponent
  ],
  imports: [
    CommonModule,
    ReactiveFormsModule,
    InputModule,
    ButtonModule
  ],
  exports: [
    SignupComponent
  ],
  providers: [SignupService] // <--- aquí
})
export class SignupModule { }

Y por último, lo inyectamos en nuestro SignupComponent:

constructor(
  private fb: FormBuilder,
  private ss: SignupService // nuevo parámetro
) {}

Y eso es todo. Ahora estamos listo para usar el servicio. 😉

Consumiendo nuestra API

Una vez que tenemos nuestro servicio listo, procedemos a usar su método checkForExists para la validación. Para esto, creamos un método llamado validateEmailNotTaken, el cual será nuestro validador.

validateEmailNotTaken(ctrl: AbstractControl) {
    return (
      this
        .ss
        .checkForExists(ctrl.value)
        .pipe(map(taken => taken ? { taken: true } : null))
    )
  }

Este método, como toda función validadora, acepta un argumento de tipo AbstractControl, el cual hace referencia al control que controla, en este caso email. Ejecutamos el método checkForExists pasándole el email que se ha ingresado en el textbox. Una vez que lo ejecutamos, hacemos un map del Observable, con el fin de transformar la respuesta por una personalizada. En este punto ya tenemos la respuesta booleana, es decir, si existe el usuario o no. Finalmente, si existe retornamos un objeto { taken: true }, el cual será añadido al objeto errors del FormControl y que podrá ser accedido por el template. En caso contrario, retorna simplemente null.

Finalmente, agregamos el validador al array de validadores asíncronos del control email:

ngOnInit() {
    this.suForm = this.fb.group({
      email: new FormControl('', [
        Validators.required,
        Validators.email
      ], [ // lo agregamos aquí
        this.validateEmailNotTaken.bind(this)
      ]),
      password: new FormControl('', [
        Validators.required,
        Validators.pattern('^(?=.*[0-9])(?=.*[a-zA-Z])([a-zA-Z0-9]+)$')
      ])
    })
  }

Si ejecutamos la aplicación e ingresamos un email que previamente hemos guardado, veremos el siguiente mensaje de error:

¡Genial! Ya tenemos nuestro formulario completamente validado. 😎

Registrando el usuario

Ya tenemos las validaciones, ahora nos falta registrar al usuario si las ha pasado todas. Para esto, vayamos a signup.service.ts y añadamos el siguiente método:

 /**
   * 
   * @param data | User information of the user
   * @returns User the recently created user
   */
  public register(data: User): Observable<User> {
    return Observable.create((sub: Subscriber<User>) => {
      this.apollo.mutate({
        mutation: gql`
          mutation Register($data: UserInput!) {
            createUser(data: $data) {
              id,
              email
            }
          }
        `,
        variables: { data }
      })
      .subscribe((value: ApolloQueryResult<any>) => {
        const created: User = value.data.createUser
        sub.next(created)
        sub.complete()
      })
    })
  }

Este método es parecido a nuestra consulta anterior. Recibe un argumento de tipo User y retornamos un Observable<User>. Dentro del Observable.create ejecutamos el método mutate de Apollo para ejecutar una mutation y le pasamos como variable $data, el objeto User que hemos recibido. Finalmente, nos subscribimos al Observable, obtenemos la información del usuario creado y la despachamos.

Este método lo llamamos desde el método signup de SignupComponent, el cual se disparará en el evento submit del formulario. El nuevo método signup queda así:

public signup() {
    const user = new User
    user.email = this.email.value
    user.password = this.password.value
    // agregamos esto
    this.ss.register(user).subscribe((created: User) => {
      alert('Registro exitoso')
      this.suForm.reset()
    })
  }

Una vez que hemos establecido los datos del usuario, se lo pasamos a register, este usará Apollo para ejecutar la mutación createUser, retornará la respuesta, la guardamos en un objeto User y la retornamos al Observer. Si nos subscribimos, tendremos a disposición al usuario recientemente creado. Para terminar, hacemos uso del método FormGroup#reset para restablecer los valores de los controles.

Y eso es todo. Ahora ya tenemos nuestro formulario completamente funcional. 😉

Recuerda que el código está disponible en Github. ¡Nos vemos!

Creando una API con GraphQL y Apollo | Parte II

gugadev — Mon, 28 Jan 2019 19:44:59 +0000

En el tutorial anterior vimos cómo crear una API GraphQL en Node.js usando apollo-server y type-graphql, entre otros y cómo consumirla mediante el cliente integrado, el cual es prisma-playground. En el presente tutorial, crearemos una aplicación en Angular que consuma el API de manera programática, además de incorporar funcionalidades extras como validación asíncrona. Dicho esto, vamos a ello.

Preparación

Lo primero es preparar nuestro entorno. Necesitamos la última LTS de Node.js así como la última versión de la CLI de Angular. Si no tienes instalado Angular, entonces mira la documentación para saber cómo instalarlo.

Procedemos a crear nuestro proyecto simple, sin routing:

ng new signup-form --style=scss

En unos segundos (o minutos, dependiendo de tu conexión) tendremos un proyecto listo que soporte para Sass.

Lo siguiente es agregar apollo al proyecto. Esto lo hacemos mediante:

ng add apollo

Angular procederá a instalar apollo y sus dependencias y además, a configurar el proyecto por nosotros.

Ahora ya podemos correr el proyecto, para esto solo ejecuta yarn start. Una vez hecho esto ya estamos listo para empezar a codear. 😉

Empezar a codear

Nuestro estilo será darkie, como se puede apreciar en el cover de este post 😏. Para ello, vamos a crear nuestro tema por medio de directivas. Si aún no sabes qué son, te invito a ver mi tutorial de directivas.

Vamos a crear una directiva para estilizar nuestras cajas de texto. Para esto, ejecutmaos:

ng g d ui/input/base

Nos creará una directiva base.directive.ts. Esta directiva lucirá así:

@Directive({
  selector: '[appBaseInput]'
})
export class BaseDirective {

  @HostBinding('class')
  elementClass = 'txt txt-base'
}

Lo que haremos con esta directiva es aplicarle las clases txt y txt-base. Este código lo pondremos en un archivo llamado base.directive.scss, en el mismo nivel que la directiva.

.txt {
  background-color: transparent;
  border: none;
  border-bottom: 2px solid rgba(255,255,255,.15);
  color: rgba(255,255,255,.75);
  font-size: 15px;
  font-weight: bolder;
  height: 50px;
  letter-spacing: 2px;
  transition: border-color 300ms ease;
  width: 100%;

  &:placeholder {
    color: rgba(255,255,255,.4);
    font-size: 15px;
  }

  &:focus {
    border-bottom-color: rgba(255,255,255,.75);
    outline: none;
  }

  &.error {
    border-bottom-color: #f39c12;
    color: #f39c12;
  }
}

Sencillo. Su fondo será transparente, y solo tendrá un border inferior, similar a material design, el cual se aclarará cuando se haga foco sobre él.

Ahora, creamos la directiva para nuestro botón. Para esto, generamos una nueva directiva con:

ng g d ui/button/primary

Y la modificamos de la siguiente manera:

@Directive({
  selector: '[appPrimaryButton]'
})
export class PrimaryDirective {
  @HostBinding('class')
  elementClass = 'btn primary'
}

Y su respectivo código CSS. De nuevo, en un archivo llamado primary.directive.scss:

.btn {
  border: none;
  border-radius: 25px;
  font-family: 'Open Sans';
  font-size: 15px;
  letter-spacing: 1px;
  height: 50px;
  width: 100%;

  &.primary {
    background-color: #333;
    color: rgba(255,255,255,.9);

    &:hover:not(:disabled), &:active:not(:disabled) {
      background-color: darken(#333, 10%);
    }
    &:disabled {
      background-color: #222;
      color: rgba(255, 255, 255, .3);
      cursor: not-allowed;
    }
  }
  &:focus {
    outline: none;
  }
}

Una vez que tenemos nuestras directivas, tenemos que crear un módulo para cada una:

ng g m ui/button/
ng g m ui/input/

E importamos y exportamos las directivas en los módulos:

@NgModule({
  declarations: [
    BaseDirective
  ],
  imports: [
    CommonModule
  ],
  exports: [
    BaseDirective
  ]
})
export class InputModule { }

@NgModule({
  declarations: [
    PrimaryDirective
  ],
  imports: [
    CommonModule
  ],
  exports: [
    PrimaryDirective
  ]
})
export class ButtonModule { }

Por último, nos dirigimos hacia src/app/styles.scss e importamos nuestros dos hojas de estilos:

@import "./app/ui/input/base.directive";
@import "./app/ui/button/primary.directive";

// Reset CSS
html {
  box-sizing: border-box;
}
*,
*:before,
*:after {
  box-sizing: inherit;
  margin: 0;
  padding: 0;
}
body {
  font-family: 'Open Sans';
}

Ahora nuestras directivas ya están listas para usar. 😎

Creación del formulario

Seguimos con la creación del formulario. Para esto, como es costumbre, hacemos uso de la CLI de Angular:

ng g c signup
ng g m signup

Hemos generado un componente y un módulo. El componente, debemos incluirlo en el módulo, así mismo, debemos incluir los módulos InputModule y ButtonModule. Veamos como queda SignupModule:

@NgModule({
  declarations: [
    SignupComponent
  ],
  imports: [
    CommonModule,
    ReactiveFormsModule,
    InputModule,
    ButtonModule
  ],
  exports: [
    SignupComponent
  ]
})
export class SignupModule { }

Expliquemos un poco hasta aquí. Lo que hemos hecho es primero crear dos directivas junto con sus módulos. Para que puedan usarse estas directivas, los módulos que las contienen deben de incluirse en el módulo del componente en donde se desea usar.

ButtonModule --> ButtonDirective
     |                  |
     ∨                  ∨
SignupModule --> SignupComponent

También importamos el módulo ReactiveFormsModule para habilitar al componente SignupComponent de usar este comportamiento de formularios reactivos, como veremos próximamente. Lo siguiente es exportar SignupComponent para que pueda usarse fuera de su módulo, ya que este componente lo usaremos en el módulo principal.

Ahora nos enfocaremos en nuestro componente. Como sabemos, un componente Angular se divide en dos, que son un template y hoja de estilos más su clase controladora. El template es simplemente HTML ligeramente modificado con atributos de Angular. Nuestro template se verá así:

<div class="container">
  <div class="overlay"></div>
  <section class="side">
    <div class="overlay"></div>
  </section>
  <form [formGroup]="suForm" (ngSubmit)="signup()">
      <figure class="image">
        <img src="/assets/img/nike.svg" alt="signup image">
      </figure>
      <article class="controls">
        <div class="form-group">
          <label for="email">correo</label>
          <input type="email" id="email" formControlName="email" placeholder="Ingresa tu correo" autocomplete="off" appBaseInput [ngClass]="{ error: email.dirty && email.errors }">
          <span class="error" *ngIf="email.errors && email.errors.email">Ingrese un correo válido</span>
          <span class="error" *ngIf="email.errors && email.errors.taken">El email ya está registrado</span>
        </div>
        <div class="form-group">
          <label for="password">contraseña</label>
          <input type="password" id="password" formControlName="password" placeholder="Ingresa tu contraseña" autocomplete="off" appBaseInput [ngClass]="{ error: email.dirty && password.errors }">
          <span class="error" *ngIf="password.errors">Ingrese letras y números</span>
        </div>
      </article>
      <footer class="actions">
        <button type="submit" appPrimaryButton [disabled]="suForm.invalid">Empezar</button>
      </footer>
  </form>
</div>

Si no sabes cómo usar Reactive Forms, mira este tutorial.

Fíjate que a los elementos input le hemos agregado nuestra directiva appBaseInput y al button, la directiva appPrimaryButton. Al hacer esto, les inyectamos las clases CSS que hemos previamente definido.

Ahora veamos nuestro controlador:

import { User } from './../models/user';
import { Component, OnInit } from '@angular/core'
import { FormBuilder, FormGroup, Validators, AbstractControl, FormControl } from '@angular/forms'
import { map } from 'rxjs/operators'

@Component({
  selector: 'app-signup',
  templateUrl: './signup.component.html',
  styleUrls: ['./signup.component.scss']
})
export class SignupComponent implements OnInit {
  suForm: FormGroup

  constructor(
    private fb: FormBuilder
  ) {}

  public signup() {
    const user = new User
    user.email = this.email.value
    user.password = this.password.value
    // hacer algo con el usuario
  }

  ngOnInit() {
    this.suForm = this.fb.group({
      email: new FormControl('', [
        Validators.required,
        Validators.email
      ]),
      password: new FormControl('', [
        Validators.pattern('^(?=.*[0-9])(?=.*[a-zA-Z])([a-zA-Z0-9]+)$')
      ])
    })
  }

  get email(): AbstractControl {
    return this.suForm.get('email')
  }

  get password(): AbstractControl {
    return this.suForm.get('password')
  }
}

Bastante sencillo como podemos ver. Creamos el FormGroup, los campos FormControl y les agregamos algunas validaciones, como required, email y pattern.

Finalmente agreguemos el código CSS para que se vea genial 😎

.container {
  background-color: #0F223F;
  background-color: #131313;
  height: 100vh;
  width: 100%;

  > .overlay {
    background-color: rgba(0,0,0,.6);
  }

  .side,
  &.container {
    background: url('/assets/img/dark-mountains.jpg') no-repeat;
    background-size: cover;
    position: relative;

    > .overlay {
      background-color: rgba(0,0,0,.5);
      height: 100%;
      left: 0;
      position: absolute;
      top: 0;
      width: 100%;
    } 
  }

  form {
    margin: 0 auto;
    max-width: 480px;
    padding: 40px;
    position: relative;
  }

  .image {
    height: 150px;
    margin-top: 30px;
    text-align: center;

    img {
      height: 100%;
    }
  }

  .controls {
    display: grid;
    grid-template-columns: 1fr;
    grid-gap: 40px 0;
    margin-top: 40px;
    padding: 20px 0;

    label {
      color: rgba(255, 255, 255, .9);
      display: block;
      font-family: 'Exo 2';
      font-size: 13px;
      letter-spacing: 3px;
      padding-bottom: 10px;
      text-transform: uppercase;
    }
    span.error {
      color: #f39c12;
      display: block;
      font-family: 'Exo 2';
      font-size: 12px;
      padding: 10px 0 0 0;
      text-transform: uppercase;
    }
  }
  .actions {
    margin-top: 20px;
  }
}

@media only screen and (min-width: 1200px) {
  .container {
    display: flex;

    form {
      background: #131313;
      flex: 0 0 480px;

      .overlay { display: none; }
    }
    .side {
      flex: 1;
    }
  }
}

Para terminar, importemos el SignupModule en AppModule y pongamos nuestro SignupComponent en el template de AppComponent:

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
    SignupModule,
    GraphQLModule,
    HttpClientModule
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

<app-signup></app-signup>

¡Y esto es todo! Si ejecutamos con yarn start obtendremos algo así:

Genial, ¿no? En el próximo tutorial le añadiremos funcionalidad al formulario. 😉

Angular Reactive Forms | Fundamentos

gugadev — Mon, 28 Jan 2019 16:27:04 +0000

Reactive Forms es un módulo que nos provee Angular para definir formularios de una forma inmutable y reactiva. Por medio de este módulo podemos construir controles dentro de un formulario y asociarlos a las etiquetas HTML del template sin necesidad de usar explícitamente un ngModel. A diferencia de Angular Forms, Reactive Forms hace uso de Observables y Streams para mantener trackeada los datos del formulario, lo cual nos permite interceptarla y transformarla por medio de operadores usando RxJs.

Para empezar a usar Reactive Forms necesitamos importar e incluir el módulo ReactiveFormsModule:

@NgModule({
  declarations: [
    SignupComponent
  ],
  imports: [
    CommonModule,
    ReactiveFormsModule,
    InputModule,
    ButtonModule
  ],
  exports: [
    SignupComponent
  ]
})
export class SignupModule { }

Anatomía de un formulario reactivo

Una vez que tenemos importado el módulo, podemos usarlo en nuestro componente y template. La estructura de nuestro formulario con Reactive Forms tiene la siguiente forma.

<form [formGroup]="myForm" (onSubmit)="doSomething()">
  <input formControlName="email" />
  <input type="password" formControlName="password" />
  <button type="submit">Registrarme</button>
</form>

Vemos que tiene algunos atributos interesantes. El primero es formGroup. Este atributo para decir que: "este formulario será controlado por el elemento suForm dentro del controlador.

El siguiente atributo es formControlName, el cual lo usamos para decir que este control será asociado con el campo que definamos en el controlador.

Ahora veamos el controlador:

@Component({
  selector: 'app-myform',
  templateUrl: './myform.component.html',
  styleUrl: './myform.component.scss'
})
export class MyFormComponent implements OnInit {
  myForm: FormGroup

  constructor(private fb: FormBuilder) {}

  ngOnInit() {
    this.myForm = this.fb.group({
      email: new FormControl(''),
      password: new FormControl('')
    })
  }
}

Analicemos un poco esto. Si te fijas, cada elemento que definimos dentro de this.fb.group({ ... }) tiene el mismo nombre que el valor que pasamos en el atributo formControlName de los inputs del template. Esto es porque estamos asociando el elemento HTML con el objeto FormControl que estamos creando, de esta manera, podemos establecer y obtener los valores en el input por medio de este objeto.

Manejando valores

Por medio de un FormControl podemos tanto obtener como establecer valores de un control en el HTML de una manera programática y reactiva. Veamos un ejemplo de ello.

Para obtener el valor de un control nos basta con obtener el control y hacer uso de la propiedad value:

const email = this.myForm.get('email').value

Y para establecer datos, usamos el método setValue:

this.myForm.get('email').setValue('ejemplo@hola.com')

Validación de campos

Uno de los puntos más importantes en la construcción de formularios es la validación. Validar correctamente nuestros campos nos protege de entradas maliciosas y nos provee también una mejor experiencia de usuario. La validación de campos reactivos es simple. Volvamos atrás, hacia la definición de nuestros campos.

this.myForm = this.fb.group({
  email: new FormControl(''),
  password: new FormControl('')
})

Es aquí en donde vamos a poner nuestras validaciones. Por defecto, Angular nos provee de validaciones para la gran mayoría de casos. Puedes ver la lista de validaciones aquí. Veamos cómo los podemos agregar:

this.myForm = this.fb.group({
  email: new FormControl('', [
    // validaciones síncronas
    Validators.required,
    Validators.email
  ], [
    // validaciones asíncronas
  ]),
  password: new FormControl('')
})

Como podemos observar, para agregar validaciones a un control basta con pasarle al constructor de FormControl un segundo parámetro, el cual es un arreglo de funciones validadoras. Es aquí en donde debemos agregar nuestras validaciones.

Sin embargo, existen otro tipo de validaciones, llamadas Validaciones asíncronas, la cuales, como su nombre indica, pueden retornar tanto una Promesa como como un Observable.

Validaciones asíncronas y personalizadas

Este tipo de validaciones pueden retornar solo una estructura asíncrona, como por ejemplo una Promesa o un Observable. Veamos como luce una validación personalizada y asíncrona:

validateEmailNotTaken(ctrl: AbstractControl) {
  return (
    this
     .checkForExists(ctrl.value)
     .pipe(map(taken => taken ? { taken: true } : null))
  )
}

Como podemos ver es bastante sencilla. En este ejemplo, validamos que el email que se ingresa no está actualmente usado por alguna otra persona. Esto lo hacemos por medio del método checkForExists, el cual usa el HttpClient para retornar un Observable con un booleano para saber si existe o no. Si existe, retornamos un objeto con la propiedad taken a la cual podemos acceder desde el template, y si no, retornamos simplemente null, indicando que no hay error.

Internamente, esta validación es resuelta por Angular, obteniendo el valor plano que engloba el observable. Simple, ¿verdad?

Propiedades útiles

Las clases FormGroup y FormControl tiene muchas propiedades útiles. Por ejemplo, FormGroup tiene entre sus propiedades a valid, el cual es un booleano que te dice si el formulario es válido, basado en si los controles han pasado las validaciones. La clase FormControl tiene propiedades como dirty, para saber si el control ya ha contenido valores anteriormente (luego de borrar), touched para saber si el control ya ha sido "tocado" (luego de perder el foco) y errors, que retorna un objeto con los errores de validación (las claves del objeto serán los nombres de las validaciones).

Veamos como podemos utilizar estas propiedades en nuestro template:

<form [formGroup]="myForm" (onSubmit)="doSomething()">
  <input formControlName="email" [ngClass]="{ error: email.dirty && email.errors }" />
  <span *ngIf="email.errors && email.errors.email">Ingrese un email válido</span>
  <span *ngIf="email.errors && email.errors.taken">El email ya ya sido registrado</span>
  <input type="password" formControlName="password" [ngClass]="{ error: password.dirty && password.errors }" />
  <span *ngIf="email.errors && email.required">Ingrese su contraseña</span>
  <button type="submit" [disabled]="myForm.invalid">Registrarme</button>
</form>

Excelente, nuestro formulario ahora nos indica los errores que tenemos en tiempo real, además el botón de submit se desactivará mientras el formulario contenga errores. Veamos con un poco más de detalle qué hemos hecho aquí.

En esta línea decimos: "agrega la clase 'error' al input si este ya ha tiene valores ingresados y si contiene cualquier error".

<input formControlName="email" [ngClass]="{ error: email.dirty && email.errors }" />

En esta otra línea, decimos: "muestra este span si el email ya ha sido registrado":

<span *ngIf="email.errors && email.errors.taken">El email ya ya sido registrado</span>

¡De esta manera tenemos un formulario validado y con una buena experiencia de usuario!

Conclusiones

Como sabemos, validar un formulario es muy importante, especialmente cuando nos enfrentamos a un público con skills técnicos. Así mismo, recuerda que la validación debe hacerse tanto en el lado cliente, como en el servidor. En este aspecto, Angular nos ayuda en la validación del primer tipo con validaciones tanto síncronas como asíncronas, permitiéndonos formularios seguros, complejos y usables. 😉

Angular Directives

gugadev — Mon, 28 Jan 2019 14:09:15 +0000

Una directiva es un atributo que cambia la apariencia o comportamiento de un componente. Imagina que es como un "inyector" de código CSS/JS. Una directiva es una clase decorada con @Directive, decorador que acepta un objeto. Entre las propiedades del objeto le pasamos uno escencial, el cual es selector y por medio del cual le indicamos el nombre del atributo que inyectaremos en otros componentes. Veamos cómo luce:

import { Directive } from '@angular/core'

@Directive({
  selector: '[myAwesomeAttribute]'
})
export class MyAwesomeDirective {

}

Si quisiéramos usar ese atributo, sería en el template del componente:

<div myAwesomeAttribute></div>

Sin embargo, la directiva por sí misma no realiza nada. Para modificar la apariencia o comportamiento de un elemento debemos hacer uso de algunas herramientas..

Cambiando la apariencia

Para inyectar clases CSS a un elemento, podemos realizarlo de dos formas:

Usando ElementRef
Usando @HostBinding

ElementRef

Nos permite acceder al elemento nativo (DOM) que es host (anfitrión) de nuestra directiva. Si, por ejemplo, el host es un elemento div, obtendremos dicho elemento del DOM. Esto se hace de la siguiente manera:

constructor(ref: ElementRef) {
  const el = ref.nativeElement as HTMLElement
  el.classList.add('my-awesome-class')
}

El código anterior le dice a Angular: "Hey, quiero que me inyectes en el constructor, la referencia al elemento en donde esta directiva está seteada.". Una vez hecho esto, podemos tener acceso al elemento DOM por medio de la propiedad nativeElement. A partir de aquí, depende de ti lo que quieras hacer con él.

HostBinding

Por medio de esta decoración podemos "bindear" datos en el host. Por ejemplo, podemos decirle qué clases css inyectar sin necesidad de usar el feo ElementRef. Esto lo hacemos pasando como atributo del decorador, el nombre de la propiedad/atributo del elemento objetivo. Veamos como se el ejemplo anterior usando este método.

// Lo hacemos directamente como propiedad
@HostBinding('class') elementClass = 'my-awesome-class'

Y eso es suficiente para inyectar la clase my-awesome-class en el elemento.

Cambiando el comportamiento

Vimos como @HostBinding nos permite cambiar la apariencia. Existe otro decorador llamado @HostListener que nos permite escuchar por eventos del elemento y extender su funcionalidad. Veamos un ejemplo:

import { Directive, HostListener } from '@angular/core'

@Directive({
  selector: '[myAwesomeAttribute]'
})
export class MyAwesomeDirective {
  @HostListener('click')
  onElementClick() {
    // hacer algo
  }
}

De esta manera, logramos extender la funcionalidad del elemento objetivo. Sencillo, ¿verdad?

Estableciendo valores

Una directiva también nos permite establecer valores desde el host. Esto, se logra de la misma forma que con componentes: por medio del decorador @Input.

// como propiedad
@Input() property: string

Y lo usaríamos de la siguiente manera:

<div myAwesomeDirective="hi"></div>

Ejemplo

Vamos a realizar un ejemplo que incluya las tres características de las directivas que hemos visto: @HostBinding, @HostListener e @Input.

@Directive({
  selector: '[appMemoButton]'
})
export class MemoButtonDirective {
  @Input('appMemoButton') key: string
  @HostBinding('class') elementClass = 'btn btn--memo'

  @HostListener('click')
  public onClick() {
    const counter = parseInt(localStorage.getItem(this.key), 10)
    localStorage.setItem(this.key, counter + 1)
  }
}

<button appMemoButton="registerButtonClicks">Register</button>

El ejemplo anterior es bastante simple. La idea general es guardar en nuestro navegador la cantidad de veces que se haga click sobre un botón.

Para esto, aceptamos que cada botón pase a la directiva su propio identificador para guardarse y que no se confunda con otros botones.

@Input('appMemoButton') key: string

Lo siguiente es añadir clases CSS que previamente hemos definido.

@HostBinding('class') elementClass = 'btn btn--memo'

Y por último, cuando se haga click en el botón, interceptamos el evento para agregar al contador de clicks de ese botón, una unidad.

@HostListener('click')
public onClick() {
  const counter = parseInt(localStorage.getItem(this.key), 10)
  localStorage.setItem(this.key, counter + 1)
}

Conclusiones

Las directivas pueden ser muy útiles; los usos son variados. Podemos usarlos para agregar temas, extender eventos, etc. Por ejemplo, un uso muy común es para los UI Kits, en donde se define, por medio de directivas, los tipos de botones, cajas de texto, dropdowns, etc. El uso que le das depende como siempre de ti. 😉

Creando una API con GraphQL y Apollo - Parte I

gugadev — Fri, 25 Jan 2019 17:54:24 +0000

Nota: Este tutorial, por su complejidad, será divido en dos partes. La primera, que es el presente escrito, será dedicado al backend usando GraphQL y Apollo junto con TypeGraphQL. El segundo, al frontend usando la última versión de Angular.

Source code

En el tutorial anterior aprendimos los conceptos básicos de GraphQL. Vimos qué eran las variables, las queries, mutations, entre otras cosas. Porque no es suficiente quedarse con la teoría, vamos a ponernos manos a la obra para practicar lo aprendido.

Preparación del proyecto

Antes que nada, recuerda utilizar la última versión LTS de Node. Así mismo, puedes usar tanto NPM como Yarn.

La lista de paquetes que necesitamos instalar es:

@types/bcryptjs
@types/graphql
@types/lokijs
@types/pino
apollo-server
bcryptjs
class-validator
graphql
lokijs
pino
pino-pretty
reflect-metadata
type-graphql
typedi

Las dependencias de desarrollo son las siguientes:

@types/node
nodemon
ts-node
tslint
typescript

Por último, agrega el script start para que corra nodemon ejecute ts-node y corra nuestra aplicación:

{
  "scripts": {
    "start": "nodemon --exec ts-node src/main.ts --watch src/ --ignore src/database/data.json"
  }
}

Creando los modelos

Para enfocarnos en GraphQL vamos a usar una base de datos en memoria.

Lo primero será crear los modelos, en nuestro caso solo tenemos uno al cual llamaremos User:

// user.type.ts
import {
  ObjectType,
  Field,
  Int
} from 'type-graphql'

@ObjectType()
export default class User {
  @Field(type => Int)
  id: number
  @Field()
  email: string
  @Field()
  password: string
}

Este tipo solo contiene tres campos:

id: representa la PK.
email
password

Nota que type-graphql nos da tipos opcionales como Intcuando los tipos de JavaScript no nos son suficientes. Por ejemplo, por defecto, number es mapeado a un Float de GraphQL. Por esta razón, por medio del parámetro type, le decimos que es de tipo INT.

A su vez, esta misma clase será nuestro modelo con el que trabajará el motor de base de datos (siempre pensando en reutilizar 😉).

Creando el servicio

Ahora procedemos a crear el servicio para User. Este se ve así:

// user.service.ts
import { Service } from 'typedi'
import { hash, genSalt } from 'bcryptjs'
import db from '../database/client'
import User from './user.type'
import UserInput from './user.input'

@Service()
export default class UserService {
  private datasource = db.getCollection('users')

  findByEmail(email: strng): User {
    return this.datasource.findOne({ email })
  }
  async create(data: UserInput): Promise<User> {
    const body = {
      ...data,
      id: this.datsource.count() + 1,
      password: await hash(data.password, await genSalt(10))
    }
    const { id } = this.datasource.insert(body)
    return this.find(id)
  }
}

Lo primero a notar es que el servicio está anotado con el decorador Service. Este decorador nos permite registrar una clase como un servicio en el contenedor DI para posteriormente inyectarlo en algún otro sitio.

El resto es realmente simple. Como propiedad tenemos datasource, la cual contiene la colleción users que hemos recuperado de la base de datos.

Finalmene tenemos dos métodos los cuales son findByEmail que encuentra un usuario por medio de su email y create el cual recibe un argumento de tipo UserInput, hashea su password plano, lo inserta en la colección y finalmente retorna el documento creado.

Suena bien, pero, ¿qué viene a ser UserInput? 🤔

Argumentos personalizados

Recorarás que en el tutorial anterior hablamos de input, los cuales son tipos que engloban campos para ser pasados como un conjunto a través de un solo argumento en las consultas. Tomando este concepto, procedemos a crear nuestro propio input.

import { IsEmail } from 'class-validator'
import {
  InputType,
  Field
} from 'type-graphql'

@InputType()
export default class UserInput {
  @Field()
  @IsEmail()
  email: string
  @Field()
  password: string
}

Te darás cuenta que es muy similar a User, ¿cierto? La única diferencia es la decoración InputType, por medio de la cual indicamos que esta clase es una estructura input. Además, como somos muy cuidadosos, validamos el campo email por medio de la decoración isMail, validación propiedad del paquete class-validator y que será automática, la misma que nos retornará un error a través de GraphQL si proveemos un valor erróneo para el campo.

Creando el Resolver

Bien, hasta aquí ya tenemos los tipos, ahora procedamos a crear la consulta y la mutación con sus respectivos resolvers. Para esto, creamos una clase y la anotamos con Resolver, como muestro a continuación:

import {
  Resolver,
  Arg,
  Query,
  Mutation,
  Int
} from 'type-graphql'
import User from './user.type'

@Resolver(of => User)
export default class UserResolver {

}

Por medio de la decoración Resolver indicamos que esta clase contendrá uno o más resolvers y además, por medio del argumento of le indicamos a quién pertenecerá; en este caso, a User. Ahora procedemos a incluir el servicio de User para consultar a la base de datos y retornar desde las consultas y mutaciones.

// imports anteriores
import { Inject } from 'typedi'

@Resolver(of => User)
export default class UserResolver {
  @Inject() private service: UserService
}

Listo. Pero, ¿Qué ha pasado aquí? 🤔

La decoración @Inject "inyecta" la dependencia (una instancia) en una variable o argumento, dependencia que debe ser del mismo tipo que el de la variable. Cuando hacemos uso de @Inject lo que hacemos es decirle al contenedor:

Hey, ¿Puedes buscar en tu registro si tienes una clase llamada ´
UserService? Si la tienes, necesito que me des una instancia y la guardes en la variable service.

¿Se entendió? Genial. Una vez que ya hemos incluido la dependencia de UserService ya estamos listos para usar sus métodos. Ahora, definamos nuestra Query. Esta se encargará de encontrar un usuario por medio de su id:

// imports anteriores
import {
  ...
  Arg, // agregamos
  Query, // agregamos
  Int // agregamos
} from 'type-graphql'

@Resolver(of => User)
export default class UserResolver {
  ...
  @Query(returns => User, { nullable: true })
  user(@Arg('email') email: string) {
    return this.userService.findByEmail(email)
  }
}

Por medio del decorador Query indicamos que dicho método representa una consulta. Esta decoración acepta dos parámetros: el tipo de retorno y un array de opciones, el cual es opcional. Por medio de ese array le decimos que esta consulta puede retornar null, debido a que cuando un usuario no se encuentre, lo que será retornado será null. En caso contrario obtendríamos un error al retornar null.

En el argumento id, proveemos un decorador de tipo Arg, al cual le pasamos un nombre. Finalmente, cuando se ejecute el método, buscará en la base de datos ese email y retornará el usuario asociado.

La anterior definición se traduce al siguiente esquema GraphQL:

type Query {
  user(email: String!): User
}

Sencillo, ¿no?. Ahora seguimos con nuestra mutación, la cual será encargada de crear un usuario en la base de datos. La definición del método es bastante similar a la consulta:

// imports anteriores
import {
  ...
  Mutation // agregamos
} from 'type-graphql'
import UserInput from './user.input'

@Resolver(of => User)
export default class UserResolver {
  ...
  @Mutation(returns => User)
  user(@Arg('data') data: UserInput) {
    return this.userService.create(data)
  }
}

Fíjate en el argumento del método, ya no le pasamos el type en el decorador Arg porque ya lo hacemos por medio de Typescript. Lo que hará type-graphql es usar Reflection para ver los tipos de los parámetros y hacer el mapeo correcto. ¡Es genial!

Lo anterior se traducirá a lo siguiente:

type Mutation {
  createUser(data: UserInput!): User
}

DI, Base de datos y Apollo

Ya tenemos casi todo lo que necesitamos, solo nos falta unos pequeños pasos. El primero es configurar nuestro container de inyección de dependencias. Para esto, hacemos lo siguiente:

import { Container } from 'typedi'
import { useContainer } from 'type-graphql'

export default () => {
  useContainer(Container)
}

Importamos el container desde typediy se lo pasamos a type-graphql para que lo configure por nosotros. Eso es todo lo que necesitamos hacer para tenerlo funcionando y poder proveer e inyectar dependencias.

Lo siguiente es crear nuestra bases de datos. Como dijimos al inicio del tutorial, será una base de datos en memoria, así que como es de suponer, el setup será sencillísimo:

// database/bootstrap.ts
import * as Loki from 'lokijs'

const db: Loki = new Loki('data.json')
db.addCollection('users')

export default db

Fíjate que en el momento en que instanciamos la base de datos, creamos una colección llamada users, que es donde se guardarán los usuarios que vayamos creando.

Finalmente, necesitamos crear nuestro servidor GraphQL usando Apollo. Veamos como luce:

// server/index.ts
import { ApolloServer } from 'apollo-server'
import { buildSchema } from 'type-graphql'
import formatError from '../errors/argument.format'
import UserResolver from '../users/user.resolver'

/**
 * Creates a Apollo server using an
 * executable schema generated by
 * TypeGraphQL.
 * We provide a custom Apollo error
 * format to returns a non-bloated
 * response to the client.
 */
export default async () => {
  const schema = await buildSchema({
    resolvers: [
      UserResolver
    ]
  })
  return new ApolloServer({
    schema
  })
}

Lo primero que hacemos es importar los resolvers, luego pasárselos a buildSchema en forma de array para que nos genera un schema de GraphQL válido que pueda entender Apollo. Lo segundo, es instanciar ApolloServer y pasarle el schema junto con otras propiedades opcionales. Puedes ver la lista de propiedades aquí. Una vez hecho esto, ya tenemos un servidor listo para correr.

Entry point

Para terminar, creamos el archivo principal que pondrá a correr el servidor de Apollo. Para esto, solo importamos la función que crea el servidor y ejecutamos la función listen, la cual pondrá en escucha al servidor.

// main.ts
import 'reflect-metadata'
import enableDI from './container/bootstrap'
import createServer from './server'
import log from './logger'

const run = async () => {
  enableDI()
  try {
    const server = await createServer()
    const { url } = await server.listen({ port: 3000 })
    log.info(`🚀  Server ready at ${url}`)
  } catch (e) {
    log.error(e)
  }
}

run()

Opcional

Error Formatter

Por defecto, cuando ocurre un error en tiempo de ejecución, GraphQL nos devuelve un gran objeto con muchos detalles, como en qué línea ocurrió, el stack trace, entre otras. Para no exponer demasiados detalles por seguridad y por simpleza, podemos crear un formateador que intercepte el error y lo modifique a nuestro antojo. Veamos un ejemplo:

// errors/argument.format.ts
import { GraphQLError } from 'graphql'
import { ArgumentValidationError } from 'type-graphql'
import { ValidationError } from 'class-validator'

/**
 * Describes a custom GraphQL error format.
 * @param { err } Original GraphQL Error
 * @returns formatted error
 */
export default (err: GraphQLError): any => {
  const formattedError: { [key: string]: any } = {
    message: err.message
  }

  if (err.originalError instanceof ArgumentValidationError) {
    formattedError.validationErrors = err.originalError.validationErrors.map((ve: ValidationError) => {
      const constraints = { ...ve.constraints }
      return {
        property: ve.property,
        value: ve.value,
        constraints
      }
    })
  }
  return formattedError
}

Los formateadores de errores reciben un error de tipo GraphQL. Este error contiene propiedades como message, paths, location, extensions, entre otras. Sin embargo, podemos solo extrar lo que necesitemos. En este caso, solo necesitamos el mensaje y los errores de validación sin mucho detalle: solo la propiedad donde ocurrió el error, su valor y las restricciones que no pasó. De esta manera tenemos errores personalizados.

Para habilitarlo, solo se lo pasamos a la opción formatError del constructor de ApolloServer:

return new ApolloServer({
    schema,
    formatError
  })
}

Run, Forrest, Run!

Llegó la hora de la verdad. En este punto no hay marcha atrás: o corre o te disparas en la sien 😝 Para correr el servidor ejecuta el clásico npm start.

Si vamos a localhost:3000 veremos el Playground para empezar a jugar. ¡Ejecuta la consulta y mutación que aparece en la imagen para ver los resultados!

En la próxima entrega de esta serie veremos como consumir esta API desde Angular usando el cliente de Apollo. ¡Nos vemos! 🤘

DEV Community: gugadev

Making Videoconferences with React and Jitsi!

Custom elements in React using a custom JSX pragma

gugadev / react-ce-ubigeo

Example using a custom JSX pragma for enable better tooling for custom elements.

How to test

Background

Passing objects/arrays to custom elements

Binding custom events

Creating a custom JSX pragma

Using the custom JSX pragma

Conclusion

Shadow DOM: eventos, target y bubbling.

Eventos en el Shadow DOM

🚀 Bubbling, composed y composedPath:

Entendiendo el hoisting

Fases del contexto de ejecución

Fase de creación

Fase de ejecución

Quiz time!

⭐ Plus

JavaScript internals - This y el Contexto de ejecución

Contexto de ejecución

Ententiendo this

Dentro de una función

Dentro en un método

Dentro de un constructor o método

Usando bind, call o apply

Conclusión

ES6 Proxies en práctica

Proxy

Ejemplo: logging/profiling

Ejemplo: acceso seguro a propiedades

Ejemplo: query array

Conclusiones

Building Instagram/Whatsapp stories clone using Web Components 🔥

gugadev / storify

Instagram/Whatsapp stories clone built on Web Components and Web Animations API. 🔥

wc 🌐 stories

Demos

Browser support

📦 Install

💡 What's the prupose of it?

🦄 Inspiration

⚙️ How it works?

🦄 Inspiration

🛠️ Setup

Webpack

PostCSS

Typescript

🏭 Structure

📦 The <story> component.

📦 The <progress> component

📦 The <stories> component

🚀 Time to run!

✈️ Bonus: definitive proof

React

Vue

Angular

🤔 Conclusion

Creando una API con GraphQL y Apollo | Parte III

Validando que el email no esté registrado.

Creación del servicio

Importación del servicio

Consumiendo nuestra API

Registrando el usuario

Creando una API con GraphQL y Apollo | Parte II

Preparación

Empezar a codear

Creación del formulario

Angular Reactive Forms | Fundamentos

Anatomía de un formulario reactivo

Manejando valores

Validación de campos

Validaciones asíncronas y personalizadas

Propiedades útiles

Conclusiones

Angular Directives

Cambiando la apariencia

Cambiando el comportamiento

🚀 Bubbling, `composed` y `composedPath`:

Ententiendo `this`

📦 The `<story>` component.

📦 The `<progress>` component

📦 The `<stories>` component