DEV Community: GabrielOmar

Compound Component Pattern en React

GabrielOmar — Mon, 10 Jan 2022 02:58:45 +0000

Podemos definir un patrón como una técnica que nos permite llegar a la resolución de problemas de distinta índole, como por ejemplo, problemas de comportamiento, estructurales, creacionales, entre otros.

En este caso, el patrón de composición de componentes o Compound Component Pattern aplicado a React, nos permite manejar la información desde un componente padre y tener control total de todos los componentes hijos.

<ProductCard  product={product} className="bg-dark">
   <ProductImage />
   <ProductTitle  />
   <ProductButtons />
</ProductCard>

En este caso tenemos el componente ProductCard, el cual recibe como children 3 componentes los cuales también reciben información desde el padre a través del React Context, a continuación los veremos a detalle

ProductCard

import React, {
  createContext,
  ReactElement,
} from "react";
import styles from "../styles/styles.module.css";
import useProduct from "../hooks/useProduct";
import { Product, ProductContextProps } from "../interfaces";
import { ProductImage } from "./ProductImage";
import { ProductTitle } from "./ProductTitle";
import { ProductButtons } from "./ProductButtons";

export const ProductContext = createContext({} as ProductContextProps);
const { Provider } = ProductContext;


 interface Props {
  product: Product;
  children: ReactElement | Array<ReactElement>;
  className: string;
}

const ProductCard = ({ children, product, className }: Props) => {
  const { counter, increaseBy } = useProduct();

  return (
    <Provider
      value={{
        counter,
        increaseBy,
        product,
        className
      }}
    >
      <div className={styles.productCard}>
        {children}
      </div>
    </Provider>
  );
};

export default ProductCard;

ProductImage

import { useContext } from "react";
import { ProductContext } from "./ProductCard";
import noImage from "../assets/no-image.jpg";
import styles from "../styles/styles.module.css";

export const ProductImage = ({ img = "" }) => {
    const { product } = useContext(ProductContext);
    let imgToShow: string;

    if(img) {
        imgToShow = img;
    } else if(product.img) {
        imgToShow = product.img
    } else {
        imgToShow = noImage
    }

    return (
      <img
        className={styles.productImg}
        src={imgToShow}
        alt="Coffee Mug"
      />
    );
  };

ProductTitle

import { useContext } from "react";
import { ProductContext } from "./ProductCard";
import styles from "../styles/styles.module.css";

export const ProductTitle = ({ title }: { title?: string }) => {
  const { product } = useContext(ProductContext);

  return (
    <span className={styles.productDescription}>
      {title ? title : product.title}
    </span>
  );
};

ProductButtons

import { useContext } from "react";
import { ProductContext } from "./ProductCard";
import styles from "../styles/styles.module.css";

export const ProductButtons = () => {
  const { increaseBy, counter } = useContext(ProductContext);

  return (
    <div className={styles.buttonsContainer}>
      <button className={styles.buttonMinus} onClick={() => increaseBy(-1)}>
        -
      </button>
      <div className={styles.countLabel}>{counter}</div>
      <button className={styles.buttonAdd} onClick={() => increaseBy(+1)}>
        +
      </button>
    </div>
  );
};

Como podemos ver, cada componente hijo recibe diferentes Props como counter, increaseBy, product y className, sin embargo a través del React Context, tenemos el control total desde nuestro componente padre. Esto nos abre una gran variedad de posibilidades para construir componentes reutilizables e incluso librerías personalizadas. Finalmente, aclarar que la meta principal de este patrón es lograr que nuestro componente sea lo más flexible posible.

🚀Una revisión rápida a los web components con Lit 🔥

GabrielOmar — Sat, 02 Oct 2021 02:16:29 +0000

En este post tendremos una pequeña vista de como crear web components utilizando Lit 2.0 el cual hace esta tarea bastante sencilla. Además, nos da la libertad de escalar tanto como lo necesitemos. Ya sea agregando unit testing, story books, patrones de diseño, entre otros.

Personalmente, he tenido mayor experiencia trabajando con Stenciljs pero con esta librería he encontrado un mundo de posibilidades a la hora de agregar componentes independientes o módulos a una aplicación sea ya creada o una que apenas comienza.

Sintáxis de Lit

import {html, css, LitElement} from 'lit';

export class ExampleComponent extends LitElement {
  static styles = css`p { color: blue }`;

  static get properties() {
    name: {type: String},
  };

  constructor() {
    super();
    this.name = 'Somebody';
  }

  render() {
    return html`<p>Good, ${this.name}! 🚀</p>`;
  }
}
customElements.define('example-component', ExampleComponent );

En este punto es importante mencionar que lit puede trabajar con Typescript o Javascript y elegir entre uno de ellos va a depender de que necesitamos para nuestro proyecto. Asimismo, los componentes de Lit están basados en class components, tienen un ciclo de vida y manejan un método render donde usualmente muestran el HTML del componente.

La forma de llamar a nuestro componente es tan sencilla como:

<!DOCTYPE html>
<head>
  <script type="module" src="./example-component.js"></script>
</head>
<body>
  <example-component name="Gabriel"></example-component>
</body>

Algo que hace interesante a Lit, es el peso de sus componentes ya que son bastante ligeros en comparación a otras librerías generadoras de web components.

Invito a probar esta librería en su link oficial = () => https://lit.dev/

🚀Creando portales con React🚀

GabrielOmar — Wed, 08 Sep 2021 00:49:40 +0000

Hace poco tuve la oportunidad de ver como se empleaba los portales en React y me pareció una técnica bastante interesante ya que nos permite manejar de forma nativa, componentes en un nodo del DOM que viven fuera de la jerarquía del padre.

Viéndolo de otro modo, los React Portals son una especie de API que nos permite renderizar componentes saltándonos la ya conocida jerarquía del DOM.

Al comienzo uno puede pensar ´¿para qué demonios quiero romper la jerarquía del DOM?´, pues según la documentación oficial, los React Portals encajan bastante bien cuando queremos manejar un componente cuyo padre tiene estilos diferentes como un z-index o un overflow:hidden y queremos saltarnos esto. Por ejemplo, una ventana de chat, un tooltip, entre otros.

Creando un portal con React

Pues para comenzar, lo primero que se necesita es añadir la etiqueta en nuestro archivo index.html

<body>
<div id='root'></div>
<div id='myModal'></div>
</body>

Como podemos observar, el elemento myModal se encuentra al mismo nivel que el elemento root. Lo genial de los portales es que nos permitirá renderizar nuestro componente, saltándonos la jerarquía del DOM.

Como siguiente paso tenemos que crear nuestro archivo para el componente Modal

import React from 'react';
import ReactDOM from "react-dom";
import "./Modal.css";

const myModalContainer = document.querySelector("#myModal");

const Modal = ({ title, children, isOpened, closeModal }) => {
  return (
    isOpened &&
    ReactDOM.createPortal(
      <div className="modal">
        <div className="modal-title">{title}</div>
        <button onClick={closeModal}>X</button>
        <div className="modal-body">{children}</div>
      </div>,
      myModalContainer
    )
  );
};

export default Modal;

Como podemos ver en el ejemplo, ReactDOM.createPortal recibe dos argumentos, lo primero es la estructura a renderizar y luego el elemento donde queremos que aparezca.

Una vez hecho esto, solo queda añadir el paso final en nuestro componente que activará el modal, en este caso useremos App.js.

import { useState } from "react";
import Modal from "./Modal";
import "./styles.css";

export default function App() {
  const [isOpened, setIsOpened] = useState(false);

  const handleOpenModal = () => setIsOpened(true);
  const handleCloseModal = () => setIsOpened(false);

  return (
    <div className="App">
      <h1>Hello I'm Gabriel and I'm using React Portals</h1>
      <button onClick={handleOpenModal}>Open Modal</button>
      <Modal title="Success" isOpened={isOpened} closeModal={handleCloseModal}>
        This is my modal content
      </Modal>
    </div>
  );
}

De esta forma lograremos renderizar nuestro modal, a este ejemplo falto agregarle estilos 😁

🚀😎SPA, SSR Y SSG ¿cómo, cuándo y por qué?

GabrielOmar — Fri, 20 Aug 2021 15:53:37 +0000

Hace unos años, basábamos el desarrollo web en frameworks puros como son Angular, React y Vue, todos ellos proveen lo que conocemos como client-side rendering (Single Page Application). Pero, con el paso del tiempo descubrimos diferentes necesidades a la hora de renderizar las aplicaciones es ahí donde entra lo que conocemos como SSR y SGR. ¿El problema?, muchos desarrolladores no tienen del todo claro cuando optar por alguno.

Podemos diferir que no tendría mucho sentido usar SSR para una TODO App así como no tendría sentido construir tu blog usando SPA, ¿o quizás si lo tendría?.

Es ahí el detalle, no existe una lista definida de cuando usar que. Sin embargo, explicaremos en que consiste cada uno, los pro y contras para que puedas tomar la mejor decisión al desarrollar tu próxima aplicación.

Client Side Rendering

Es la forma más común de renderizado de las herramientas más populares que tenemos actualmente como Angular, React, Vuejs, Ember, etc. Con esta solución, el servidor renderiza una página en blanco con una etiqueta script que apunta al bundle de nuestra aplicación.
Esta página en blanco es mandada al navegador del cliente, el cual empieza a correr la aplicación, compila todo lo necesario y empieza a hacer las llamadas a las respectivas Apis del proyecto.

Pros

Es rápida en el servidor: ya que solo estás renderizando una página en blanco, está carga muy rápido.
Soporta SPA: Client-Side Rendering es el único que soporta las aplicaciones SPA.

Contras

No hay renderizado inicial: estás enviando una página en blanco al navegador del cliente, así que si tu aplicación es muy grande o si el visitante tiene una conexión a internet lenta, no sería muy buena idea, ¿verdad?
Seguridad: se dice mucho que comparadas a las páginas tradicionales, las SPA son menos seguras frente a un ataque de Cross-site scripting (XSS).
Empieza siendo un
vacío: esto significa que no habrá data inicial para los sistemas y scripts de SEO. Recalcar que existen herramientas en cada uno de estos frameworks basados en SPA para poder mejorar el aspecto del SEO.

Server Side Rendering

Se puede definir como la forma de renderizar una página web en el servidor en vez de usar el navegador. La principal diferencia con una SPA sería que cuando el usuario requiera pasar de una página a otra, deberá esperar unos segundos a que la página renderice en el servidor para luego ser enviada al browser.

Pros

Contenido disponible inmediatamente: ya que estás enviando HTML renderizado desde el servidor, el contenido se visualizará inmediatamente.
No hay llamadas adicionales en el cliente: lo importante de que el servidor renderice la página es que hará todas las llamadas necesarias en ese momento, en ese sentido no estarás haciendo llamadas adicionales en el lado del cliente.
Muy bueno para el SEO: al tener acceso a la web de forma inmediata, las herramientas de SEO pueden trabajar correctamente.

Contras

Lento en el servidor: recuerda que estás renderizando la página dos veces, una en el servidor y otra en el cliente. Adicional a ello, probablemente se estén llamando APIs para preparar toda la información. Todo esto, supone un tiempo que el cliente debe esperar. Sin embargo, si mejoras y optimizas el perfomance de tu aplicación, podrás manejarlo de mejor forma.
Incompatible con algunas librerías: Si alguna de tus librerías depende del document o de window, tendrás que buscar la forma de reemplazarlos ya que Node no maneja estos elementos. Una solución ideal podrían ser las custom NPM libraries.

Static Site Generation

Se podría definir como el software que crea las páginas HTML a partir de ciertos templates o fuentes de información. Le puedes dar unos artículos de texto y el generador creará la web en base a ello.

Pros

Alta velocidad: ya que todo el contenido puede ser generado en tiempo real, el cliente empezará a ver la información casi inmediatamente. ¿Lo mejor?, al tener esta fuente de información no tendrás que preocuparte por APIs externas.
No hay llamadas adicionales en el lado del cliente: idealmente no tendrás que llamar APIs externas ya que al construirse la página se harán todos los llamados necesarios.
Muy bueno para el SEO.
Seguridad: al ser generados por documentos estáticos, la posibilidad de recibir ataques de seguridad es mínima. Esto principalmente porque este tipo de webs no manejan bases de datos.
No hay servidor o backend como también se le conoce: al tener una fuente que produce estos templates de información, no tendrás que monitorear un servidor o ver problemas como los clásicos memory leak

Contras

Puede llegar a ser lento: puede llegar a volverse lento dependiendo de que tanto crezca la aplicación.
Incompatible con algunas librerías UI: por la misma razón que se comentó en las páginas SSR.

¿Cuándo usar qué?

Bajo mi experiencia, tomar esta decisión dependerá mucho del tipo de aplicación que se vaya a desarrollar. Por eso, lo ideal es primero tener los requerimientos exactos e incluso hasta donde podría escalar a corto y mediano plazo, para que de esa manera pueda satisfacer esas funcionalidades.

Hoy en día tenemos muchas herramientas para desarrollar software, debemos usarlas con responsabilidad y bajo un sustento técnico siempre:

Trucos en Angular que mejorarán el performance de tus aplicaciones.

GabrielOmar — Sat, 01 May 2021 22:42:58 +0000

Angular es un framework bastante popular en el mundo empresarial. A pesar de que tiene la curva de aprendizaje más elevada que el resto, mucha gente se anima a aprenderlo. Personalmente, a mi me gusta bastante y es por eso que acá te dejaré unos trucos que tal vez no conocías 😎

Lazy Loading

Está característica es bastante popular ya que nos permite configurar nuestra aplicación para que cargue los archivos únicamente cuando son necesarios. Por ejemplo, tenemos dos vistas donde la primera sería la presentación y la segunda el blog. Todos los recursos que se necesiten para cargar el blog, no serán 'llamados/ejecutados' hasta que el usuario no vaya a esa sección.

Destruyendo Observables

Si bien los observables son de RxJs, cuando trabajemos con Angular, los vamos a usar bastante ya sea para los servicios o estar escuchando ciertos cambios de nuestra aplicación. Sin embargo, los observables tienen la particular característica que no se destruyen por si solos sino que debemos forzar a que suceda. Esto es necesario ya que sino, nuestros observables seguirán consumiendo espacio de memoria en background y podría hacer nuestra aplicación más lenta. Formas para destruir observables hay muchas, pero una que me gusta bastante es a través del operador takeUntil, el cual podemos anteponer a nuestra suscripción con el operador pipe, también de Rxjs. Al mismo tiempo nos apoyamos de un subject de tipo void que su única función sera hacer un next() y complete() en el OnDestroy del componente. Lo mejor es que de esta manera, podemos reutilizar nuestro subject en todas las subscripciones que tengamos en nuestro componente.

Pre fetching

Está funcionalidad es sin duda demasiado buena, parecido a lo que viene por default en otras tecnologías como Gatsby, podemos hacer que algunos archivos vayan pre cargando antes que el usuario entre a esa página. Por ejemplo, si vamos a entrar a una galería al colocar el mouse sobre el botón que nos llevará, nuestra aplicación irá cargando en background las imágenes respectivas para que de esta manera la experiencia del usuario sea mucho mejor.

Si te han gustado estos trucos puedes verlos en mis diferentes proyectos de github(https://github.com/QuispeRosasGabriel) 😎 y tú tienes algún truco que te gustaría compartir?

Mi experiencia participando en la NgConf 2021

GabrielOmar — Wed, 28 Apr 2021 22:36:09 +0000

La NgConf es la conferencia mundial de Angular que se organiza en Estados Unidos. Este año, por la coyuntura del Covid-19, el evento pasó a ser virtual. Sin duda, esto permitió que mucha más gente pueda inscribirse como speaker y/o participante.

En este evento se juntan varios de los mejores desarrolladores del mundo que trabajan en empresas como Google, Amazon, Facebook, Uber, Apple, Microsoft, etc. Y es una gran oportunidad para aprender de ellos.

Mi experiencia fue bastante buena ya que pude participar en una lightning talk con un tema que tiene bastante acogida por varios desarrolladores: Angular and Stencil working together. Aquí pude explicar de como estas tecnologías trabajan juntas y que beneficios traen a nuestras aplicaciones. La sesión fue grabada y estará en los canales oficiales de la NgConf en unas semanas.

Finalmente, destacar también mi experiencia como participante, aprendí mucho de las tendencias emergentes con diferentes herramientas tecnológicas como Angular, Typescript, etc. Sin duda, una experiencia que volvería a repetir y espero poder volver a ser speaker en la siguiente NgConf 🚀😎

Some advice for React projects structure

GabrielOmar — Sat, 10 Apr 2021 17:30:55 +0000

Most of frameworks have a strict way to name the components and folders of the project. But, React allows us to make a custom structure. So here are some advice that should be used on your React projects.

First of all, this post is based on a create-react-app application so we can see the details here:

Structuring components

In many projects, components are in a shared folder that are used in all the app. So, in this case I'm gonna show 3 types of components:

Components: they are a group of components that have isolated styles and logic. For example, an Input component used in a Form.
Containers: these type of components have a strict rule, they interact with api request and pass or get the information from their children.
Pages: usually are different types of components working together.

Is important to say that for each page, container and component, we have to create a folder to keep isolated logic and styles.

And what about the global constants?

Is a good practice to keep global functions and constants in a separate file, so we can change it quickly.

Also, we can manage a service file that has all the endpoints for that section.

Custom hooks and global helpers

These files manage a reusable function. For example, a custom hook that can change the currency.

So we can manage them in two global folders that should be called hooks and utils, so we can access to there from any part of the app.

*Global Functions

*Global Hooks

Name of folders

This part is very important because we can save a lot of time if we can read our code quickly.

We can follow Kebab Case rule and use (-). However, there are some general rules:

Components: Is must that our components starts with capital letter. For example, if we have an userform, we should call it UserForm.
Containers: Usually are descriptive and have the name of the children. For example, if the child is UserForm, our container should be calle UserFormContainer.
Hooks: It is recommended by the team that mantain React to write the hooks with use. So, if we have a custom hooks that changes the currency, it should be callde useChangeCurrency.
Request: About the request files, usually are called like => [get | post | mutation | query…]-[name of the request]-[request].
Types: These files just save types of actions so they should called like => [name of the action that will be typed]-types.

Conclusion

If we show an organized structure for our projects, we will be able to add new feature quickly. Also, it will make easier to work in teams.

Angular VS React 🥊

GabrielOmar — Thu, 08 Apr 2021 03:04:06 +0000

Una de las preguntas que más me hacen en las entrevistas laborales es: '¿Cual es mejor para ti? ¿Angular o React?'. Lo que tenemos que tener claro es que ambos tienen características que pueden o no ayudarte en el desarrollo de tu aplicación. A continuación entraremos más en detalle.

Peso de la aplicación el producción

Un punto bastante importante es el peso final del bundle de nuestros proyectos, en este caso una aplicación estándar de react bien desarrollada genera un bundle mucho más ligero que una aplicación desarrollada en Angular con similares características.

Flexibilidad vs trabajo estricto

En mi opinión personal y habiendo trabajado con ambas herramientas en proyectos grandes y medianos, puedo decir que React ofrece cierta libertad que no encuentras en Angular. Además, posee mayor cantidad de compatibilidad con third party libraries lo que puede ser beneficioso para agregar funcionalidades de forma rápida. Por otro lado, con Angular el manejo de la aplicación es más estricta y rigurosa, haciendo que desarrollemos bajo patrones estrictos. Un claro ejemplo sería el patrón MVC o MVP. Además, al tener como base TypeScript, nos obliga a tener nuestras variables tipadas.

Manejo de formularios

Si bien en React podemos utilizar Formik, React Hooks Form u otra forma para manejar formularios, cuando usamos Angular tenemos la característica de los reactive forms, que son bastante poderosos si se usan de forma correcta. Nos permite manejar formularios dinámicos con campos a donde podemos suscribirnos y escuchar por cambios.

Estructura de carpetas

Angular tiene bien definida la estructura a seguir para las aplicaciones. Almacenando métodos compartidos en servicios, manejando transformadores de data en pipes e incluso agrupando componentes en módulos. Por otro lado, React tiene mucha más flexibilidad y te permite ordenar tus componentes como mejor te parezca. Si bien esto se oye genial, puede causar que los principiantes creen proyectos enredados y poco mantenibles.

PO: ambas herramientas tienen una finalidad, desarrollar componentes del lado del cliente. Si bien la forma de trabajo es distinta, lo ideal es poder entender bien las bases y trabajar con el que te sientas más cómodo. Algo que casi seguro es que si dominas uno y dominas JS/TS, podrás trabajar con cualquier framework frontend. 😎

Module federation, ¿el futuro del micro frontend?

GabrielOmar — Wed, 07 Apr 2021 03:43:49 +0000

Estoy seguro que en alguna ocasión hemos escuchado de los micro servicios, una técnica bastante interesante en desarrollo backend que permite dividir tareas en sub tareas independientes que convivan entre si, a través de module federation y del micro frontend podemos lograr un concepto similar en el lado del cliente.

Si bien este concepto no es nuevo, la forma en como los frameworks de hoy en día se adaptan a esta técnica, permiten un desarrollo eficiente y granular. Pero, ¿en qué consiste exactamente una aplicación hecha con micro frontend?. Veamos la gráfica

Como podemos ver consiste en dividir el frontend de un aplicación en pequeñas micro aplicaciones que cumplen un rol específico y se comunican entre si, de esta manera podemos trabajar de forma aislada en cada funcionalidad y hacer que convivan entre si, sin que exista esa dependencia.

Algunos aspectos importantes de los micro frontend y reglas que se brindaron en la NGConf2020 (Conferencia mundial de Angular 2020):

Tecnologías independientes => cada micro app es trabajada con la tecnología que mejor se adapte a las funcionalidades de forma que el equipo es libre de decidir.
Código independiente => en la mayoría de casos y como buena práctica, se pide que cada aplicación conviva con si misma, es decir de no manejar estados o variables globales.
Establecer reglas de trabajo => se debe coordinar entre todos los equipos la forma en que se trabajara los estilos, los storage sea local storage, session storage, etc con el fin de manejar un estándar en todo el proyecto.
El DOM es la api => es preferible usar los browser events para la comunicación. Si es realmente necesario manejar una api general, tratar de mantenerlo lo más simple posible.
Apuntar al clean code, es una prioridad => si bien se trabaja en equipos separados, se debe manejar un estándar para que cualquier desarrollador front del proyecto pueda dar mantenimiento a cualquiera de las micro aplicaciones.

Bien ahora, hablemos acerca de Module Federation:

Con la llegada de Webpack5, tenemos la posibilidad de trabajar con micro frontend de forma sencilla, a través de un archivo de Webpack, podemos configurar en totalidad la salida y que archivos se estarán compartiendo de nuestros micro frontend.

Veamos el archivo de la aplicación principal en Angular...

const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
const mf = require("@angular-architects/module-federation/webpack");
const path = require("path");

const sharedMappings = new mf.SharedMappings();
sharedMappings.register(
    path.join(__dirname, '../../tsconfig.json'),
    ['session-lib']
);

module.exports = {
  output: {
    uniqueName: "shell"
  },
  optimization: {
    // Only needed to bypass a temporary bug
    runtimeChunk: false
  },
  plugins: [
    new ModuleFederationPlugin({

        // For hosts (please adjust)
        remotes: {
          'admin': "admin@http://localhost:3000/remoteEntry.js"
        },

        shared: {
          "@angular/core": { singleton: true, strictVersion: true },
          "@angular/common": { singleton: true, strictVersion: true },
          "@angular/router": { singleton: true, strictVersion: true },
          "@angular/material/button": { singleton: true, strictVersion: true },
          "@angular/material/icon": { singleton: true, strictVersion: true },
          "@angular/material/toolbar": { singleton: true, strictVersion: true },
          "@angular/animations": { singleton: true, strictVersion: true },
          "@angular/cdk": { singleton: true, strictVersion: true },
          ...sharedMappings.getDescriptors()
        }

    }),
    sharedMappings.getPlugin(),
  ],
};

Ahora conozcamos uno de los micro sitios anclados a esta micro app...

const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
const mf = require("@angular-architects/module-federation/webpack");
const path = require("path");

const sharedMappings = new mf.SharedMappings();
sharedMappings.register(
    path.join(__dirname, '../../tsconfig.json'),
    ['session-lib']
);

module.exports = {

  optimization: {
    runtimeChunk: false
  },
  plugins: [
    new ModuleFederationPlugin({

        // For remotes (please adjust)
        name: "admin",
        filename: "remoteEntry.js",
        exposes: {
          './Dashboard': './projects/remote/src/app/dashboard/dashboard.module.ts',
          './Contact': './projects/remote/src/app/contact/contact.module.ts',
        },

        shared: {
          "@angular/core": { singleton: true, strictVersion: true },
          "@angular/common": { singleton: true, strictVersion: true },
          "@angular/router": { singleton: true, strictVersion: true },
          "@angular/material/button": { singleton: true, strictVersion: true },
          "@angular/material/icon": { singleton: true, strictVersion: true },
          "@angular/material/toolbar": { singleton: true, strictVersion: true },
          "@angular/animations": { singleton: true, strictVersion: true },
          "@angular/cdk": { singleton: true, strictVersion: true },
          ...sharedMappings.getDescriptors()
        }

    }),
    sharedMappings.getPlugin(),
  ],
};

Como hemos podido ver, los archivos de configuración son bastante sencillos de configurar. Algo importante para resaltar es que son altamente escalables, el límite va a depender mucho frente a que aplicación estemos. Otro detalle a tener en cuenta es que si bien Webpack 5 ya fue lanzado, Angular 11 aún no tiene todo el soporte acerca del mismo, personalmente aún no lo usaría para producción, pero cada uno tiene su punto de vista y opinión 😎

Ya entendí HTML, CSS y JS, ahora qué sigue?

GabrielOmar — Fri, 02 Apr 2021 20:56:10 +0000

Muchas veces cuando una persona empieza en el camino del desarrollo web se le recomienda aprender las bases como son HTML, CSS y JS, pero ¿Qué sigue después de aprender estos tres?

Lo que actualmente se solicita en diversas ofertas laborales para frontend developer es el conocimiento en algún framework Javascript, a continuación hablaremos de algunos de los más buscados:

Angular

Framework creado por Google, permite desarrollar aplicaciones robustas bajo patrones estrictos como MVC (model-view-controller) y MVP(model-view-presenter), entre otros. Utilizan TypeScript para aprovechar el tipado y las características del mismo. Separa los componentes en 4 archivos principales donde guardamos la lógica, la UI, las pruebas unitarias y los estilos respectivamente. Algo importante es que cada componente esta basado en clases y tiene métodos propios para manejar el ciclo de vida.

import { Component, ComponentFactoryResolver, Injector } from '@angular/core';

@Component({
  selector: 'my-app',
  templateUrl: './app.component.html',
  styleUrls: [ './app.component.css' ]
})
export class AppComponent  {

  constructor() {
  }

  public ngOnInit() {
      alert('Utilizando Angular')
  }
}

Aprende más de Angular en: https://angular.io/

React

Librería mantenida por Facebook y diversos grupos de desarrolladores. Nos permite crear componentes utilizando JSX, de esta forma podemos combinar Javascript dentro de nuestro HTML. Cada componente puede tener su archivo con extension .js o .jsx de acuerdo a las reglas que manejemos en nuestro proyecto.

import React from "react";

export default function App() {
  return (
    <div>
      <h1>Utilizando React 😎!</h1>
    </div>
  );
}

Aprende más de React en: https://reactjs.org/

Vue

Framework progresivo mantenido por la comunidad, trabaja principalmente con el patrón MVVM (model-view-view-model). Al ser progresivo permite ir desde lo más básico hasta escalar nuestro proyecto a funcionalidades más complejas. Además, maneja ciertas similitudes con Angular con el two way data binding, las directivas, entre otros.

<template>
  <div id="app">
    <img alt="Vue logo" src="https://vuejs.org/images/logo.png">
  </div>
</template>

<script>
 export default {
   name: 'App',
 }
</script>

Aprende más de Vue en: https://vuejs.org/

Class components vs Functional components

GabrielOmar — Fri, 02 Apr 2021 19:59:51 +0000

Cuando empezamos a desarrollar una aplicación en React siempre esta presente la duda entre usar componentes orientado a clases o componentes funcionales. En este artículo trataremos de explicar las ventajas y desventajas de cada uno.

Class Components

Fueron la primera forma de escribir componentes en React, tienen un ciclo de vida particular además de manejar un scope cerrado. Se debe considerar que al ser una clase, podemos implementar y heredar, entre otras técnicas de la programación orientada a objetos (POO).

Sobre su ciclo de vida, tienen métodos propios que nos permite ejecutar distintos eventos en casi cualquier momento.

A continuación veremos un pequeño ejemplo de la sintaxis de un class component en React.

import React from 'react';

class MyHomePage extends React.Component {

 render() {
   return <h1>Soy un Class Component en React</h1>
 }
}

export default MyHomePage;

Functional Components

A diferencia de los class components, no tienen acceso a los lifecycle methods como tal, sino más bien trae los increíbles Hooks, los cuales nos facilitarán el desarrollo y control de elementos en nuestro componente. Los principales son useState, useEffect, useRef, useContext, useReducer, useMemo.

Otro punto importante en este tipo de componentes es el scope que manejamos, tenemos cierta flexibilidad para usar elementos que estén por fuera de nuestro componente.

Conozcamos un poco más de los hooks:

Recordar que los hooks pueden convivir perfectamente con los class components y de esta manera lograr una migración progresiva del proyecto 😎

Web APIs bastante útiles

GabrielOmar — Wed, 06 Jan 2021 22:43:30 +0000

Existe una gran cantidad de Web APIs que nos permiten implementar funcionalidades increíbles en nuestras aplicaciones.

En este artículo comentaremos algunas que en algún momento podrías necesitar.

Web XR Device API

Se consideran un grupo de estándares que dan compatibilidad para acceder a dispositivos de realidad virtual (VR) y realidad aumentada (AR) incluyendo los sensores. Todo esto desde un sitio o aplicación web. Algunas de las funcionalidades que nos ofrece son:

Encontrar dispositivos de salida para realidad virtual o aumentada que sean compatibles.
Renderizar una o varias escenas 3d en el dispositivo a una velocidad adecuada que no afecte la experiencia del visitante.
Reflejar la salida de una pantalla 2D.
Crear vectores que representan los movimientos de los controles de entrada.

Vibration API

Esta increíble API permite que un sitio web pueda acceder al hardware de vibración y que el dispositivo se mueva o vibre. Es bastante útil para enviar notificaciones o algún tipo de interacción física con el usuario. A un nivel avanzado, podemos incluso controlar el patrón de vibración del dispositivo.

Notifications API

Bastante usado en las PWA (Progressive Web Application), permite que nuestro sitio web controle las notificaciones del dispositivo. Algo importante es que estas son independientes, quiere decir que se pueden mostrar incluso estando en otra pestaña o aplicación.

No hay duda que estas Web APIs nos permiten llevar nuestras aplicaciones al siguiente nivel. Todo depende de las funcionalidades que necesitemos y el nivel de interacción que deseamos tener con el usuario :)