Pablo Fonseca Moncada

Cuando se utiliza Type Inference (:=) lo que se hace realmente es medir la capacidad de la arquitectura de la máquina. Go detecta por medio de los datos de la memoria ROM la capacidad de la computadora para poder procesar dígitos. Si la computadora es de x64 bits entonces go decide utilizar tipos int64. Si la arquitectura es de x32 bits entonces Go escoge int32. No es para nada recomendable especificar de forma explícita el tipo de dato concreto en tipos de dato int o cualquiera que tenga diferentes variantes, primero porque no todas las computadoras podrán procesar uno u el otro y segundo porque si en el futuro se necesita almacenar un dato mayor a la hora de ir escalando el software, se puede encontrar con errores por el simple hecho de que el dato de la variante fue especificado concretamente en el código.

Yo como uso ASDF en la empresa para gestionar versiones de lenguajes usé la documentación de ASDF Golang

https://github.com/kennyp/asdf-golang

Saludos!

Te habla un estudiante que tuvo muchos problemas configurando el repositorio que te da el curso.

Si no quieres pasar por el mismo trayecto extenso que yo pasé te recomiendo que utilices mi Fork del repositorio original.

Este es el Link al nuevo repositorio que te puedo ofrecer: https://github.com/pablofonseca-dev/react-desde-cero

Cambios Realizados del Repositorio Original

En él hice bastantes cambios, y varios de ellos se adaptan al curso de React desde 0 del año 2021.

Entre los cambios que hice:

1. Creación de una API nueva con JSON Server, para solucionar problemas de las rutas en las imágenes de los cursos. Anteriormente EDTeam tenía varios de sus sistemas en Drupal, pero ahora los assets están montados en AWS S3.

2. Actualización con .env.example y .env.local, la ruta a Axios se pasa a variable local. Debes crear un nuevo archivo .env.local y pegar lo que hay en .env.example

3. Corrección de errores en el state de Forms, eliminé que el nombre sea undefined y que tanto el correo como el nombre puedan ser cambiados correctamente.

4. Reemplazo de la sintaxis de React Routes con la nueva sintaxis de la versión más reciente.

5. Cambio en el hook de useCourse para que sea más semántico y fácil de entender.

Happy coding!

Buenas a todos,

Desde que empecé con React y empecé a manipular la metodología de Brad Frost me surgió la duda de cómo se debería de implementar correctamente.

Para poner un ejemplo de cómo lo estoy haciendo pondré un proyecto simple de ejemplo:

Empecé a crear los Atoms, los cuales reciben por sus Props sus atributos y valores. Por lo habitual las clases HTML5 de esos componentes también se envían por Props y se relacionan con algún Toolkit de estilos como lo es Bootstrap o Tailwind CSS.

Sin embargo, mi intuición me dijo que todos los Components deberían tener la flexibilidad de tener sus atributos y clases de estilos dinámicas, por lo que pensé pasarlas por Props.

Entonces por poner un caso pondré como ejemplo este Atom de Input:

import PropTypes from 'prop-types';

const Input = (
   {
       type, 
       name, 
       id, 
       className, 
       placeholder,
       disabled,
       onChange
   }
) => {
   return (
       <input
       type={type}
       name={name}
       id={id}
       className={className}
       placeholder={placeholder}
       disabled={disabled}
       onChange={onChange}
     />
   );
}

Input.propTypes = {
   type: PropTypes.string.isRequired, 
}

Input.defaultProps = {
   name: '', 
   id: '', 
   className: '', 
   placeholder: '', 
   disabled: false,
   onChange: undefined
}

export default Input; 

Ahora bien, luego de crear ese Atom vi un problema, y es que si todo lo recibo por Props significa que el Parent Component debería de pasarle esos Props. Es decir, el Particle debería de pasarle al Atom "Input" los Props. Ahora bien ¿Qué pasa si tengo más de un Atom y esa Particle también debe recibir Props?

Mi preocupación es que si todos los componentes reciben mediante Props sus valores entre más alto sea el Parent Component en el VirtualDOM, más tendrá parámetros que deberá pasarle a sus hijos.

Entonces, me gustaría saber la manera correcta de no tener un Props Hell.

Fecha: Nov 18 2021

Buenas noches,

Efectivamente como el profesor Beto Quiroga indica al final cuando uno consigue trabajo en una empresa se va a encontrar más que todo con componentes de clase.

En mi caso entré hace unos días a trabajar a una empresa multinacional y en mi primer Pair-Programming (programación en parejas donde te guían por primera vez en el código fuente) fue con React, ReactContext, TypeScript y MaterializeUI básicamente. Mi primera impresión fue la cantidad de código exagerada para cada componente de React 1000 líneas en promedio por componente, y la segunda que cada componente tenía la sintaxis de componentes de clase.

Lo que me explicó el programador fue que antes los componentes orientados a funciones no tenían tantas funcionalidades, por lo que en aquel entonces usaron el approach de componentes orientados a clases. Sin embargo, justo el día que yo entré también me comentó que parte de las metas de ese proyecto era migrar todos los componentes a componentes funcionales, parte de la responsabilidad de los desarrolladores más orientados a calidad y a supervisión de normas en el proyecto.

Entonces yo les recomiendo que si ese tipo de sintaxis les parece más engorrosa la estudien igual por ese caso, y si les resulta atemorizante estúdienla el doble. Aunque realmente ya uno con bastante trecho solo tiene que ver las diferencias entre ambas y listo.

El hecho de que por componente hayan 1000 líneas de código no es algo normal, se debe a problemas relacionados con arquitectura, consecuencia ocasionada por la rotación constante de desarrolladores junior de proyectos internos a proyectos internacionales.