DEV Community: Ceci Torres

Migrating a UI Component from Dojo.js to React.js

Ceci Torres — Mon, 04 Sep 2023 23:38:00 +0000

Introduction

Web development is an ever-evolving field, and staying current with the latest technologies is crucial. As React.js gains widespread popularity for its component-based architecture, migrating UI components from Dojo.js to React.js has become a necessary step for many developers.

In this article, we will walk you through the process of migrating a UI component, specifically a table, from Dojo.js to React.js. We'll pay special attention to the styling aspect, providing before-and-after examples for the table component.

Step 1: Understanding the Dojo.js Component

Before diving into the migration process, let's get acquainted with the Dojo.js table component we'll be working with. In our Dojo.js codebase, we have a table that displays data. Here's a simplified representation of how the table might look:

// Dojo.js Component
// ...

// Example inline styling in Dojo.js
const tableStyle = "border-collapse: collapse;";
const cellStyle = "border: 1px solid #ccc; padding: 8px;";

function renderTable() {
  const tableNode = document.getElementById("dojo-table");

  // Create the table element
  const table = document.createElement("table");
  table.style = tableStyle;

  // Create table rows and cells
  data.forEach(function (item) {
    const row = document.createElement("tr");

    ["name", "age", "location"].forEach(function (field) {
      const cell = document.createElement("td");
      cell.style = cellStyle;
      cell.textContent = item[field];
      row.appendChild(cell);
    });

    table.appendChild(row);
  });

  tableNode.appendChild(table);
}

// ...

Step 2: Setting Up Your React Project

To begin the migration process, you need to set up a new React project. You can achieve this by using Create React App or your preferred React project setup method.

Step 3: Creating the React Table Component

In React, we'll create a new component to replace our Dojo.js table. Here's the equivalent React component:

// React.js Component
import React from "react";

function ReactTable({ data }) {
  return (
    <div>
      <table className="react-table">
        <thead>
          <tr>
            <th>Name</th>
            <th>Age</th>
            <th>Location</th>
          </tr>
        </thead>
        <tbody>
          {data.map((item, index) => (
            <tr key={index}>
              <td>{item.name}</td>
              <td>{item.age}</td>
              <td>{item.location}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

export default ReactTable;

Step 4: Migrating Styling

In our Dojo.js example, styling is primarily done using inline styles, which can make the code harder to maintain and style consistency challenging to achieve. Here's a snippet of the inline styling applied to the Dojo.js table:

// Example inline styling in Dojo.js
const tableStyle = "border-collapse: collapse;";
const cellStyle = "border: 1px solid #ccc; padding: 8px;";

In the React.js example, we take a different approach by using CSS Modules for styling. Here's how the React component integrates styling:

// React.js Component with CSS Modules
import React from "react";
import styles from "./ReactTable.module.css"; // Importing CSS Module

function ReactTable({ data }) {
  return (
    <div>
      <table className={styles["react-table"]}>
        <thead>
          <tr>
            <th>Name</th>
            <th>Age</th>
            <th>Location</th>
          </tr>
        </thead>
        <tbody>
          {data.map((item, index) => (
            <tr key={index}>
              <td>{item.name}</td>
              <td>{item.age}</td>
              <td>{item.location}</td>
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

export default ReactTable;

Step 5: Integration

To integrate the React table component into your project, import it and use it within your desired React component. Pass the necessary data as props, as shown earlier.

Conclusion

Migrating a UI component from Dojo.js to React.js is a comprehensive process that involves not only code but also styling. By adopting CSS Modules in React, we can achieve more maintainable and organized styling, making it easier to manage and enhance the user interface.

With this migration, we not only embrace React's component-based architecture but also improve the maintainability and scalability of our codebase. The before-and-after styling examples illustrate the transition from inline styles to a more structured and modular styling approach.

Remember that migration may require some effort, but it positions your project to benefit from React's component-based development and the broader React ecosystem. As you continue to migrate other components, you'll create a more cohesive and modern web application.

5 consejos para mejorar como desarrollador frontend

Ceci Torres — Mon, 11 Apr 2022 07:26:12 +0000

1 Repasa los principios de desarrollo generales

He notado que es muy común ver ejemplos de los principios de desarrollo solamente aplicados a el lado de backend. Pero estos principios no pertenecen a una sola rama, también puedes aplicarlos en el frontend. Por ejemplo RxJS utiliza el patrón "Observer", o React que hace uso del patrón "State".

Aplicar los principios DRY o Single Responsibility Principle harán que la calidad de tu código se eleve hasta las nubes

2 Aprende sobre Design Systems

Los Design Systems sirven para tener un estándar en el Look & Feel de un proyecto. Es una biblioteca de los componentes visuales de tu interfaz, y desarrollar pensando en esto te permite tener un diseño más limpio y estandarizado en todas tus vistas.

Te recomiendo buscar mas acerca de herramientas como Storybook.js y Figma

3 Documenta tus proyectos

No tiene que ser nada sofisticado, con tener un buen Readme que explique de qué trata tu proyecto y cómo puede levantarse en local estas del otro lado. Dale un vistazo a https://www.makeareadme.com/

4 Unit testing

El testing sigue siendo una área no tan valorada en el desarrollo de software. Y de las fases que más se suelen brincar cuando tenemos deadlines apretados. No podemos estar más equivocados al hacer esto. Las pruebas unitarias permiten a los programadores mantener y cambiar el código con mayor seguridad al paso del tiempo.

Así al refactorizar el código o actualizar las bibliotecas del sistema en el futuro nos aseguramos de que el código aún funcione correctamente.

Bonus: Incluye Typescript a tu stack

Hay quienes lo odian, hay quienes lo aman. Yo al principio veía más problemático el tener que incluir otra capa de complejidad a mis proyectos. Pero después comencé a ver los beneficios que Typescript aporta: código más legible, más fácil de mantener, feedback en vivo del IDE y mucho más.

Dale una oportunidad, al principio la curva de aprendizaje será un poco difícil, pero verás que no te arrepentirás.

5 Distraete y no estudies todo el tiempo

Me ha tocado ver a compañeros desgastarse horas y horas tratando de resolver un problema. Incluso a mi me llego a suceder, me quedaba enfrascada tanto tiempo hasta que no terminará lo que sea en lo que estaba trabajando, y después comenzaba a experimentar el para mi famoso “ya no veo que dice mi código”. Y no porque en verdad ya no pudiera ver, si no que más bien el estar tanto tiempo atorado con un problema hace que perdamos el enfoque y dejemos de ver el panorama completo.
Así que recomiendo tomar descansos entre tus bloques de trabajo y parar de trabajar a la hora que termina tu jornada laboral. Es mucho más benéfico terminar de trabajar y que después te distraigas y despejes tu mente. Así podrás retomar al día siguiente con nueva energía y seguramente encontrarás la solución más rápido.

Esos fueron los consejos del día. Escribe en los comentarios qué te parecieron. Gracias por leerme.

Lecciones aprendidas como Lead Software Engineer, Parte 1

Ceci Torres — Thu, 07 Apr 2022 05:37:11 +0000

Hola, soy Cecilia y esta será una miniserie con algunas de las últimas lecciones que he aprendido en estos últimos meses como líder de un equipo de desarrolladores frontend.

El primer tema con el que quiero arrancar es como reducir el código duplicado en tus proyectos de frontend. Pongamos un ejemplo, digamos que te han solicitado desarrollar una característica nueva en tu proyecto, leer y guardar un token de autenticación en el store de tu aplicación. Es la primera vez que creas esta funcionalidad, así que lo haces. Meses después, te asignan a un proyecto nuevo y te piden nuevamente que leas y guardes un token de autenticación en el store para esta aplicación y recuerdas “Hey! Yo ya he hecho esto antes”. Así que decides copiar y pegar el código que ya habías creado.

Pasan los meses de nuevo y ¡qué crees! Adivinaste, un tercer proyecto aparece y necesita también el famoso token de autenticación. ¿Qué harás esta ocasión? ¿Volverás a copiar y pegar el código de nuevo? Suena tentador, lo sé. Es lo más fácil y sencillo de hacer, pero esta solución rápida nos deja con los siguientes problemas:

¿Qué pasa si llegan 5 proyectos nuevos? ¿Seguiremos copiando N veces más?
¿Y sí además de leer y guardar el token ahora se necesita actualizar al momento de expirar? ¿Tendré que ir manualmente a cada proyecto a extender esta funcionalidad?
¿O qué sucede si mi código tiene un error o encontré una manera más eficiente de manejar el token y necesito refactorizar? Nuevamente, tengo que ir a modificar el código en N proyectos diferentes

Como ves, no siempre lo más sencillo es más conveniente a largo plazo. Una cualidad que diferencia a un desarrollador con poca experiencia a uno más experimentado es la capacidad de adelantarse y planear a futuro como sus desarrollos puede expandirse, el famoso “ver a futuro” que has escuchado mencionar. Y este es un buen ejemplo, cuando comienzas a detectar que una funcionalidad empieza a repetirse o necesitar en más de un proyecto, seguramente estás ante un candidato de código a encapsular y empaquetar.

¿Has escuchado hablar del concepto DRY? Don't Repeat Yourself (No te repitas!) nos recuerda que cada comportamiento repetible en el código debe estar aislado (por ejemplo, separado en una función) para su reutilización. Este es un principio de diseño de software muy famoso y que si no habías escuchado hablar de él, te invito a investigar más acerca de este y otros más.

Pero volvamos al ejemplo del token. Ya tenemos identificado el fragmento de código que necesitamos separar, ahora que sigue? Mi consejo sería crear un pequeño módulo npm que solo contenga la lógica necesaria para manipular el token. Recuerda dejar este código lo más aislado de reglas de negocio de los proyectos o detalles muy particulares de los mismos, o en otras palabras: que solo tenga un solo objetivo, en este caso manipular el token, ¡no más!. (Otro principio que te invito a investigar relacionado a esto: SRP o Single Responsibility Principle)
Ya que has logrado crear tu nuevo módulo npm, ahora habrá que publicarlo en algún repositorio de módulos, puede ser en npm.js, github.com o alguno privado (sabías que GitLab tiene opción para esto? Si quisiera aprender como, déjame un comentario para saber que te interesa un artículo explicando más a detalle cómo funciona).

Por último, la parte que más me emociona, borrar el código que ya hemos migrado y reemplazarlo instalando nuestro nuevo módulo npm (Esto me hizo recordar una de mis frases favoritas; “Los buenos programadores escriben un buen código. Los grandes programadores no escriben código. Los programadores Zen eliminan el código”) La funcionalidad debe seguir trabajando como si nada hubiese cambiado, los usuarios no notarán el cambio. Pero tu yo del futuro y otros programadores si lo harán, y verán los siguientes beneficios:

Desarrollos más veloces cuando un nuevo proyecto necesite esta funcionalidad.
Propagación de fixes de bugs encontrados o extensión de funcionalidades más veloces, ya que ahora se podrá mantener el módulo por separado y solo habrá que actualizar la versión de la librería en los proyectos donde se mande llamar.
Reducción de código duplicado y estandarización de estrategias para resolver un mismo problema a lo largo de los proyectos de tu empresa

Como ves, los beneficios son muy atractivos y beneficios a largo plazo. ¿Has pensado en alguna funcionalidad de alguno de tus proyectos que podrías encapsular y reducir el código duplicado en tu trabajo? Platícame en los comentarios

Gracias por leer, nos vemos en la próxima!