El inicio de sesión de Google es una excelente función de inicio de sesión para ofrecer a los usuarios de su aplicación. Les facilita crear una cuenta e iniciar sesión.

Y lo que es aún mejor, Firebase hace que sea extremadamente fácil para los desarrolladores agregar soporte para el inicio de sesión de Google. Pero configurar el entorno de React Native puede crear algunos desafíos, que se cubren completamente en este tutorial.

React Native y Firebase SDK hacen que la implementación del inicio de sesión de Google sea bastante sencilla. Construyamos una aplicación simple que solo tenga un botón de inicio de sesión de Google. Una vez que el usuario inicie sesión con éxito en Google, mostraremos la información del usuario recuperada de su cuenta de Google, así como un botón de cierre de sesión.

También puede agregar Facebook Login a su aplicación si está interesado en brindar aún más opciones de inicio de sesión a sus usuarios. Puede consultar esta guía para iniciar sesión con Facebook en React Native con Firebase si desea obtener más información sobre cómo configurar el inicio de sesión con Facebook.

¿Por qué usar un botón de inicio de sesión de Google en aplicaciones móviles?

1. El uso de Google u otros terceros puede hacer que su proceso de autenticación sea sencillo y amigable. Los usuarios no tienen que perder tiempo en el proceso de registro, lo que mejorará enormemente sus tasas de registro y retención.
2. Es segura y protegida.
3. Los usuarios confían más en Google o Facebook que en un sitio o aplicación desconocidos en Internet.
4. Proporciona una buena experiencia de usuario. Como usuario, tenemos poca paciencia para cualquier acción o trabajo que necesitemos hacer, especialmente en una aplicación bastante desconocida que estamos probando por primera vez.

Sin más preámbulos, pasemos directamente a la parte de desarrollo de aplicaciones de este tutorial.

Configuración del proyecto Firebase

Vaya a Firebase Console y cree un proyecto de Firebase:

Aquí, necesitaremos configurar el nombre del proyecto Firebase y el identificador de la aplicación, así que primero creemos la aplicación React Native.

Creando el proyecto React Native

Primero, necesitamos crear un proyecto React Native usando el siguiente comando:

react-native init instamobile-google-login-demo

Aquí, hemos dado el nombre del proyecto como instamobile-google-login-demo. Ahora, necesitamos instalar el paquete react-native-google-signin usando el siguiente comando:

yarn add react-native-google-singin

El paquete react-native-google-signin se utiliza para implementar las funciones de autenticación de Google en la aplicación React Native. Ahora, necesitamos importar los módulos y componentes necesarios del paquete respectivo como se muestra en el fragmento de código a continuación:

import {
GoogleSignin,
GoogleSigninButton,
statusCodes,
} from 'react-native-google-signin';

A continuación, necesitamos crear los estados para manejar el estado de autenticación y la información del usuario. Para eso usamos el módulo useState como se muestra en el fragmento de código a continuación:

const [loggedIn, setloggedIn] = useState(false);
const [userInfo, setuserInfo] = useState([]);

Ahora, necesitamos crear una función de inicio de sesión para manejar la autenticación como se muestra en el fragmento de código a continuación:

_signIn = async () => {
  try {
    await GoogleSignin.hasPlayServices();
    const {accessToken, idToken} = await GoogleSignin.signIn();
    setloggedIn(true);
  } catch (error) {
    if (error.code === statusCodes.SIGN_IN_CANCELLED) {
      // user cancelled the login flow
      alert('Cancel');
    } else if (error.code === statusCodes.IN_PROGRESS) {
      alert('Signin in progress');
      // operation (f.e. sign in) is in progress already
    } else if (error.code === statusCodes.PLAY_SERVICES_NOT_AVAILABLE) {
      alert('PLAY_SERVICES_NOT_AVAILABLE');
      // play services not available or outdated
    } else {
      // some other error happened
    }
  }
};

A continuación, debemos inicializar la configuración del objeto de inicio de sesión de Google aprovechando la función useEffect :

useEffect(() => {
   GoogleSignin.configure({
     scopes: ['email'], // what API you want to access on behalf of the user, default is email and profile
     webClientId:
       '418977770929-g9ou7r9eva1u78a3anassxxxxxxx.apps.googleusercontent.com', // client ID of type WEB for your server (needed to verify user ID and offline access)
     offlineAccess: true, // if you want to access Google API on behalf of the user FROM YOUR SERVER
   });
 }, []);

Por último, necesitamos una función que maneje la acción de cierre de sesión. Para eso, vamos a implementar el método signOut como se muestra en el fragmento de código a continuación:

signOut = async () => {
    try {
      await GoogleSignin.revokeAccess();
      await GoogleSignin.signOut();
      setloggedIn(false);
      setuserInfo([]);
    } catch (error) {
      console.error(error);
    }
  };

Ahora, también necesitamos renderizar los componentes en la pantalla. Para eso, vamos a hacer uso de varios componentes como View y Button:

return (
    <>
      <StatusBar barStyle="dark-content" />
      <SafeAreaView>
        <ScrollView
          contentInsetAdjustmentBehavior="automatic"
          style={styles.scrollView}>
          <Header />

          <View style={styles.body}>
            <View style={styles.sectionContainer}>
              <GoogleSigninButton
                style={{width: 192, height: 48}}
                size={GoogleSigninButton.Size.Wide}
                color={GoogleSigninButton.Color.Dark}
                onPress={this._signIn}
              />
            </View>
            <View style={styles.buttonContainer}>
              {!loggedIn && <Text>You are currently logged out</Text>}
              {loggedIn && (
                <Button
                  onPress={this.signOut}
                  title="LogOut"
                  color="red"></Button>
              )}
            </View>
          </View>
        </ScrollView>
      </SafeAreaView>
    </>
  );

Ahora bien, si ejecutamos nuestro proyecto en el emulador obtendremos los siguientes resultados:

Bastante dulce, ¿verdad? Hemos completado la implementación (tanto de la interfaz de usuario como de la lógica empresarial) en el nivel de React Native en nuestro proyecto.

Como puede ver, tenemos un botón "Iniciar sesión con Google" que se convierte en un botón de cierre de sesión una vez que la operación de inicio de sesión se completa con éxito.

Ahora vamos a configurar el paquete de inicio de sesión de Google y la aplicación Firebase.

Configuración de los proyectos nativos de iOS y Android

Hay algunos pasos de configuración que debemos seguir antes de que el proyecto funcione por completo. En su mayoría están relacionados con el lado nativo real de la aplicación.

Para iOS

Aquí, en VSCode (o cualquier Terminal) simplemente ejecute cd ios && pod install. Luego abra el archivo .xcworkspace en Xcode (desde la carpeta ios) y asegúrese de que los Pods estén incluidos:

Para Android

1. Primero, necesitamos vincular el módulo nativo.

• En RN >= 0.60 no debería necesitar hacer nada gracias a la vinculación automática.
• En RN < 0.60 ejecute el enlace react-native link react-native-google-signin.

2. Actualice android/build.gradle con la siguiente configuración:

buildscript {
    ext {
        buildToolsVersion = "27.0.3"
        minSdkVersion = 16
        compileSdkVersion = 27
        targetSdkVersion = 26
        supportLibVersion = "27.1.1"
        googlePlayServicesAuthVersion = "16.0.1" // <--- use this version or newer
    }
...
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.2' // <--- use this version or newer
        classpath 'com.google.gms:google-services:4.1.0' // <--- use this version or newer
    }
...
allprojects {
    repositories {
        mavenLocal()
        google() // <--- make sure this is included
        jcenter()
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
    }
}

3. Actualiceandroid/app/build.gradle con la siguiente configuración:

...
dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.android.support:appcompat-v7:23.0.1"
    implementation "com.facebook.react:react-native:+"
    implementation(project(":react-native-community_google-signin")) // <--- add this dependency
}

Verifique que vinculó el módulo nativo react-native link  – pero solo si usaste react-native link!

En android/settings.gradle  deberíamos tener las siguientes configuraciones:

...
include ':react-native-google-signin', ':app'
project(':react-native-google-signin').projectDir = new File(rootProject.projectDir, '../node_modules/@react-native-community/google-signin/android')

A continuación, en MainApplication.java ,deberíamos agregar el paquete de Google como en el siguiente fragmento de código:

import co.apptailor.googlesignin.RNGoogleSigninPackage;  // <--- import

public class MainApplication extends Application implements ReactApplication {

  ......

  @Override
    protected List<ReactPackage> getPackages() {
      return Arrays.<ReactPackage>asList(
          new MainReactPackage(),
          new RNGoogleSigninPackage() // <-- this needs to be in the list
      );
    }
  ......

}

Configuración para Firebase

Para iOS

Ahora, debemos comenzar con la configuración de Firebase. En Firebase, necesitamos configurar una aplicación en la nube de Google. Pero cuando configuramos el método de autenticación en Firebase, esto también crea una aplicación en la nube de Google.

Primero, necesitamos crear la aplicación Firebase iOS para obtener GoogleServiceinfo.plist como se muestra en la siguiente captura de pantalla:

A continuación, copiamos el archivo GoogleService-info.plist al proyecto Xcode como se muestra en la siguiente captura de pantalla:

Ahora, debemos agregar la ID de cliente invertida presente en el archivo GoogleService-info.plist a los tipos de URL, como se muestra en la siguiente captura de pantalla:

El siguiente paso es ir a Info → URL Types y luego completar los URL Schemes como se muestra en la siguiente captura de pantalla:

Para Android

Primero, necesitamos crear una aplicación de Android en Firebase. Para eso, necesitamos un nombre de paquete y un certificado SHA-1 de nuestra aplicación. Luego, podemos registrar la aplicación Firebase como se muestra a continuación:

Podemos obtener el nombre del paquete en MainApplication.java de nuestro proyecto como se destaca en el fragmento de código a continuación:

A continuación, podemos obtener la clave SHA-1 en el archivo Keystore. En el directorio android/app, podemos ejecutar el comando:

cd android/app ; 
keytool -exportcert -keystore debug.keystore -list -v

Luego, aparecerá la clave SHA-1, como se muestra en la siguiente captura de pantalla:

Después de crear con éxito la aplicación de configuración de Firebase, debemos descargar el archivo google-services.json y copiarlo en el directorio, como se muestra en la siguiente captura de pantalla:

Ahora, el paso final es configurar un componente de inicio de sesión de Google en Android.

Instalación del paquete React Native Firebase

Para instalar el paquete react-native-firebase versión 6, debemos ejecutar el siguiente comando en el símbolo del sistema de nuestro proyecto:

# Using npm 
npm install --save @react-native-firebase/app 
# Using Yarn 
yarn add @react-native-firebase/app

El módulo @react-native-firebase/app debe instalarse antes de usar cualquier otro servicio de Firebase.

Para iOS

Ya tenemos GoogleService-Info.plist agregado a Xcode. Lo que queda es permitir que Firebase en iOS use las credenciales. El SDK de Firebase iOS debe configurarse durante la fase de arranque de su aplicación.

Para hacer esto, debemos abrir nuestro archivo /ios/{projectName}/AppDelegate.m , y agregar lo siguiente:

En la parte superior del archivo, necesitamos importar el SDK de Firebase:

#import <Firebase.h>

Dentro de su método didFinishLaunchingWithOptions existente, debemos agregar lo siguiente en la parte superior del método:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  // Add me --- \/
  if ([FIRApp defaultApp] == nil) {
    [FIRApp configure];
  }
  // Add me --- /\
  // ...
}

Finalmente, debemos ejecutar el siguiente comando para finalizar la instalación del paquete CocoaPods:

cd ios ; pod install

Eso es todo. Ahora hemos completado la instalación del paquete principal de Firebase en iOS

Para Android

Necesitamos configurar Firebase con credenciales de Android. Para permitir que Firebase en Android use las credenciales, el complemento de servicios de Google debe estar habilitado en el proyecto. Esto requiere la modificación de dos archivos en el directorio de Android.

Primero, agregue el complemento de servicios de Google como una dependencia dentro de su archivo android/build.gradle:

buildscript {
  dependencies {
    // ... other dependencies
    classpath 'com.google.gms:google-services:4.2.0'
    // Add me --- /\
  }
}
Lastly, execute the plugin by adding the following to the very bottom of your /android/app/build.gradle file:

apply plugin: 'com.google.gms.google-services'

Módulo de autenticación React Native Firebase

Una vez completada la instalación, debemos configurar el paquete principal de Firebase. A continuación, necesitamos instalar el módulo secundario para la autenticación. Para eso, necesitamos abrir una terminal y ejecutar el siguiente comando:

yarn add @react-native-firebase/auth

Para iOS

Solo necesitamos instalar los pods nuevamente en el símbolo del sistema:

cd ios/ && pod install

Para Android

Puede seguir las instrucciones en la documentación oficial que solo se requiere si está utilizando React Native <= 0.59 o necesita integrar manualmente la biblioteca.

Activar el inicio de sesión de Google en Firebase

Tenemos que ir a la consola de Firebase. Luego, en la sección Autenticación, debemos hacer clic en Google como se muestra en la siguiente captura de pantalla:

A continuación, debemos habilitar la configuración con la siguiente configuración y guardar la configuración como se muestra en la captura de pantalla a continuación:

En App.js, necesitamos importar la autenticación del paquete Firebase como se muestra en el fragmento de código a continuación:

import auth from '@react-native-firebase/auth';

A continuación, debemos integrar la configuración de autenticación a la función de sign-in. Después de un inicio de sesión exitoso, almacenamos accessToken y idToken en Firebase. Ahora, podemos intentar iniciar sesión con Google en nuestra aplicación de demostración React Native.

_signIn = async () => {
    try {
      await GoogleSignin.hasPlayServices();
      const {accessToken, idToken} = await GoogleSignin.signIn();
      setloggedIn(true);
      const credential = auth.GoogleAuthProvider.credential(
        idToken,
        accessToken,
      );
      await auth().signInWithCredential(credential);
    } catch (error) {

Ahora hemos completado con éxito la integración de Google Sign-in en nuestra aplicación React Native:

Podemos ver nuevos datos que se agregan a Firebase Console:

Seguimiento del estado del usuario

Para verificar el estado de inicio de sesión del usuario, usamos Firebase Auth. Para eso, necesitamos agregar el método onAuthStateChanged a useEffect para que se ejecute en cada llamada de evento componentDidMount.

Además, debemos pasar una devolución de llamada a la función denominada onAuthStateChanged como argumento, como se muestra en el fragmento de código a continuación:

useEffect(() => {
    .............
    const subscriber = auth().onAuthStateChanged(onAuthStateChanged);
    return subscriber; // unsubscribe on unmount
  }, []);

En la función onAuthStateChanged, manejamos los datos del estado local como se muestra en el fragmento de código a continuación:

function onAuthStateChanged(user) {
    setUser(user);
    console.log(user);
    if (user) setloggedIn(true);
  }

Ahora, necesitamos almacenar los datos de usuario para el estado. Luego, intente mostrar los datos del usuario después de un inicio de sesión exitoso. Para eso, necesitamos usar la siguiente pieza de código:

{!user && <Text>You are currently logged out</Text>}
{user && (
  <View>
    <Text>Welcome {user.displayName}</Text>
    <Button
      onPress={this.signOut}
      title="LogOut"
      color="red"></Button>
  </View>
)}

Obtendremos el siguiente resultado en nuestro simulador:

Cerrar sesión de Firebase

Para cerrar sesión, debemos eliminar todas las credenciales del usuario y revocar el token de inicio de sesión de Google.

Primero, debemos esperar a que el módulo GoogleSignin revoque el acceso y cierre la sesión. Luego, llamamos al método de signOut de Firebase auth para cerrar sesión con éxito.

La implementación general del código se proporciona en el siguiente fragmento de código:

signOut = async () => {
    try {
      await GoogleSignin.revokeAccess();
      await GoogleSignin.signOut();
      auth()
        .signOut()
        .then(() => alert('Your are signed out!'));
      setloggedIn(false);
      // setuserInfo([]);
    } catch (error) {
      console.error(error);
    }
  };

Como resultado, ahora podemos realizar operaciones de cierre de sesión como se muestra en el fragmento de código a continuación:

Conclusion

En este tutorial, aprendimos a configurar Google Login, además de almacenar un token de acceso, aprovechando Firebase en nuestro proyecto React Native.

Primero, creamos el proyecto React Native con todos los componentes necesarios y configuraciones de funciones. Luego, aprendimos cómo configurar Google Sign In y Firebase para las plataformas Android e iOS. Finalmente, configuramos Firebase en la aplicación React Native usando un paquete de Firebase y mostramos los datos del usuario junto con el botón de cierre de sesión.

Puede descargar el código fuente completo de este tutorial desde Github.

La mejor parte es que Firebase y Google Auth son compatibles con todos los lenguajes de desarrollo móvil, como Flutter, Swift o Kotlin. Los pasos de configuración y el enfoque arquitectónico son exactamente los mismos.

Si te gustó este tutorial de React Native, dame una estrella en el repositorio de Github y compártelo con tu comunidad. Puede consultar aún más proyectos React Native gratuitos en Instamobile. ¡Salud!

Escribir CSS puede ser realmente difícil. Y punto. Y lo entiendo: puede ser frustrante plasmar tus propias ideas o los diseños que recibes de tu equipo de diseño.

Estoy seguro de que muchos de ustedes han pasado por el mismo dolor al menos un par de veces en sus carreras de desarrollo.

Pues ya no. Porque es hora de aprender una interesante herramienta que nos quita gran parte de la carga. Y no, no es Bootstrap: se llama Tailwind CSS.

Aunque Tailwind existe desde hace tiempo, es posible que aún no lo conozcas. Puede que no hayas oído hablar de él o que no sepas si aprender una nueva tecnología relacionada con CSS te hará la vida más fácil.

Y, de hecho, existen muchas formas de escribir CSS, como Vanilla CSS3, LESS, SCSS, Bootstrap, styled-components, Windi CSS y muchas más... uf. Menuda lista, ¿verdad?

Espero que esta breve guía te ayude a entender Tailwind CSS y sus beneficios para que puedas decir "Este es. Esto es".

Bueno, basta de cháchara. Entremos de lleno.

¿Qué es el CSS atómico?

Antes de adentrarnos en Tailwind CSS, vamos a entender qué es Atomic CSS. Según CSS Tricks

"CSS atómico es el enfoque de la arquitectura CSS que favorece las clases pequeñas y de propósito único con nombres basados en la función visual."

Es como hacer clases que se supone que tienen un único propósito. Por ejemplo, hagamos una clase bg-blue con el siguiente CSS:

.bg-blue {
  background-color: rgb(81, 191, 255);
}

Ahora bien, si añadimos esta clase a una etiqueta <h1>, obtendrá un fondo azul cuyo color será rgb(81, 191, 255) como se puede ver en el código anterior.

Y aquí está el HTML:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <div><h1 class="bg-blue">Hello world!</h1></div>
  </body>
</html>

Así que este HTML resultará en algo como esto:

Ahora imagínese escribir algo tan útil single-purpose CSS rules y guardarlos todos en un archivo global CSS. Sé que es una inversión de una sola vez, pero piensa en esto: ahora puedes utilizar estas clases de ayuda de un solo propósito desde donde quieras.

Sólo necesitas que tu archivo HTML consuma ese archivo CSS global, y ya está. Ahora también puedes utilizar combinaciones de estas clases de ayuda en una sola etiqueta HTML.

Veamos otro ejemplo, ¿de acuerdo?

Vamos a crear un archivo CSS con las siguientes reglas:

.bg-blue {
  background-color: rgb(81, 191, 255);
}
.bg-green {
  background-color: rgb(81, 255, 90);
}
.text-underline {
  text-decoration: underline;
}
.text-center {
  text-align: center;
}
.font-weight-400 {
  font-weight: 400;
}

y luego consumirlo en nuestro archivo HTML de la siguiente manera:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <div><h1 class="bg-blue">Hello world 1</h1></div>
    <div><h1 class="text-underline">Hello world 2</h1></div>
    <div class="text-center">
      <h1 class="bg-green font-weight-400 text-underline">Hello world 3</h1>
    </div>
  </body>
</html>

Bien, ahora esto generará el siguiente resultado:

?️ Puntos a tener en cuenta aquí:

• Combinación de varias clases de ayuda:Mira cómo he combinado varias clases de ayuda en la línea 14 de la etiqueta <h1>, concretamente bg-green, font-weight-400 y text-underline. Todo surtió efecto en mi texto Hello world 3.
• Reutilización de clases auxiliares: En el ejemplo anterior, fíjese en cómo text-underline se utiliza varias veces en las líneas 12 y 14.

Mira cómo hemos podido añadir diferentes estilos sin ni siquiera salir de la página HTML. Bueno, puede que digas: "Oye, tuvimos que escribir esas clases de ayuda o utilidad en el archivo CSS global... ¿Qué pasa con eso?". Bueno, lo entiendo. Esa fue definitivamente la inversión inicial que tuvimos que hacer para empezar.

Y, por supuesto, quién sabe cuántas de estas clases de ayuda o utilidad de propósito único tendríamos que hacer si quisiéramos seguir esta arquitectura Atomic CSS.

Y ahí es donde entra Tailwind CSS. El concepto de CSS atómico no es nuevo, pero Tailwind CSS lo lleva a otro nivel.

Tailwind CSS - Un framework CSS de utilidades básicas

Tailwind CSS, según su propio sitio web, es un "framework CSS que prioriza las utilidades" que proporciona varias de estas clases de utilidades de un solo propósito que puedes utilizar directamente dentro de tu marcado para diseñar un elemento.

Algunas de las clases de utilidad que utilizo con frecuencia estos días son:

• flex: Se utiliza para aplicar Flexbox a un <div>
• items-center: para aplicar la propiedad CSS align-items: center; a un <div>
• rounded-full: para hacer circular una imagen, etc.

En serio, no me es posible enumerarlas todas porque hay muchas de estas clases de utilidad. Pero la mejor parte es, que no tenemos que escribir estas clases de utilidad nosotros mismos y mantenerlos en cualquier archivo CSS global. Las obtenemos directamente de Tailwind.

Puedes obtener una lista de todas las clases de utilidad que ofrece Tailwind en la página de documentación. También si estás trabajando en VS Code, puedes instalar una extensión llamada Tailwind CSS IntelliSense y te dará auto-sugerencias mientras sigues escribiendo las clases de utilidad, como se muestra en la imagen de abajo.

Cómo configurar Tailwind CSS

Hay varias formas de configurar el CSS de Tailwind en tu proyecto, todas ellas mencionadas en su documentación.

Tailwind CSS funciona sin problemas con una plétora de frameworks como Next, React, Angular y más, e incluso con nuestro HTML original.

Para la siguiente demostración práctica estoy utilizando Tailwind CSS con una aplicación Next. Para configurar una aplicación Next con Tailwind CSS directamente, utilice el siguiente comando:

Con npx

npx create-next-app --example with-tailwindcss with-tailwindcss-app

O con yarn

yarn create next-app --example with-tailwindcss with-tailwindcss-app

Una vez configurado el proyecto, puede sumergirse en el siguiente paso para crear un componente de tarjeta básico

Demostración práctica

Construyamos un componente de tarjeta en un proyecto Next.

// Card.js file
// to be rendered in index.js

import React from "react";

const Card = () => {
  return (
    <div className="relative w-96 m-3 cursor-pointer border-2 shadow-lg rounded-xl items-center">
      {/* Image */}
      <div className="flex h-28 bg-blue-700 rounded-xl items-center justify-center">
        <h1 className="absolute mx-auto text-center right text-2xl text-white">
          Image goes here
        </h1>
      </div>

      {/* Description */}
      <div className="p-2 border-b-2">
        <h6>
          Lorem ipsum dolor sit amet consectetur adipisicing elit. Facilis
          beatae nulla, atque et sunt ad voluptatum quidem impedit numquam quia?
          Lorem ipsum dolor sit amet consectetur adipisicing elit. Facilis
          beatae nulla, atque et sunt ad voluptatum quidem impedit numquam quia?
        </h6>
      </div>

      {/* Tech stack used */}
      <div className="flex flex-wrap items-center m-2">
        <span className=" border border-blue-300 rounded-2xl px-2 my-1 mx-1">
          #React
        </span>
        <span className=" border border-blue-300 rounded-2xl px-2 my-1 mx-1">
          #Redux
        </span>
        <span className=" border border-blue-300 rounded-2xl px-2 my-1 mx-1">
          #Javascript
        </span>
      </div>

      {/* Links */}
      <div className="flex flex-wrap items-center rounded-b-xl border-t-2 bg-white">
        <button className="border rounded-2xl bg-blue-600 text-white shadow-sm p-1 px-2 m-2">
          Go to Project
        </button>
        <button className="border-2 border-blue-600 rounded-2xl text-blue-600 shadow-sm p-1 px-2 m-2">
          Github
        </button>
      </div>
    </div>
  );
};

export default Card;

El resultado es la siguiente tarjeta que se muestra en la interfaz de usuario:

Mira lo fácil que es dar estilo al componente de la tarjeta sin siquiera salir del archivo Card.js. No es necesario escribir ningún archivo CSS adicional.

Utilizando flex con un <div> aplica regla CSS display: flex;. ¿Desea añadir position: relative; a un <div>? Sólo tiene que añadir relative en la className y ya está.

También podemos añadir diferentes modificadores como hover, active, focus y así sucesivamente para renderizar condicionalmente las clases de utilidad. Es posible aplicar reglas CSS complejas como esta:

.some-class-name {
          --tw-space-x-reverse: 0;
          margin-right: calc(0.5rem * var(--tw-space-x-reverse));
          margin-left: calc(0.5rem * calc(1 - var(--tw-space-x-reverse)));
}

Con solo mencionar space-x-2 en la etiqueta <div>. Genial, ¿verdad?

¿Tenemos que mencionar explícitamente estos estilos en algún archivo CSS global? Por supuesto que no. Tailwind lo hace automáticamente por nosotros. Esa es la belleza de Tailwind.

Aún no hemos terminado... hay muchas otras ventajas. Veámoslas ahora.

Ventajas de Tailwind CSS

Just-In-Time (JIT) ofrece tiempos de compilación rapidísimos

Antes de la versión 3 de Tailwind, se purgaban todos los estilos para eliminar los que no se utilizaban, de modo que la compilación de producción fuera lo más pequeña posible.

Según Tailwind, la compilación de producción solía tener entre 5 y 10 kB. Pero esa es la historia en producción. En un entorno de desarrollo, el CSS puede llegar a ser realmente grande, especialmente si usamos mucha configuración personalizada.

Con la v3 y superiores, Tailwind lanzó una nueva característica llamada compilador Just-in-Time. El compilador JIT evita compilar todo el CSS por adelantado y compila sólo el CSS como y cuando lo necesitamos.

El resultado son tiempos de creación rapidísimos en todos los entornos. Y como los estilos se generan a medida que los necesitamos, no es necesario purgar los estilos no utilizados. Esto significa que el CSS en todos los entornos será el mismo. Esto nos ayuda a deshacernos del miedo a que cualquier CSS importante sea purgado en producción.

Es obstinado y flexible al mismo tiempo

El CSS de Tailwind es obstinado. Especifica algunas restricciones cuando se trata de estilo, y si me preguntas esto es bueno, ya que nos ayuda a mantener la parte de diseño a los que realmente lo entienden.

Basta con mirar una de las clases de utilidad para añadir un box-shadow a su <div>.

Como puede ver, solo hay 8 variantes de sombra que Tailwind proporciona. Hay valores preestablecidos para el desplazamiento vertical y horizontal, el desenfoque, la dispersión, el color y la opacidad. Por eso Tailwind es obstinado.

Trata de dar una opinión sobre qué valores de propiedad elegir en casi todas las propiedades de estilo que existen. Y créeme, para la mayoría de los casos, estas 8 variantes (para box-shadow) será más que suficiente para crear una gran interfaz de usuario.

Por ejemplo, en el ejemplo práctico anterior, he utilizado shadow-lg en la clase principal <div> para conseguir esa bonita sombra exterior.

El uso de la misma variante de una determinada clase de utilidad en distintas zonas de la interfaz de usuario también garantiza la uniformidad en toda la aplicación y mejora la experiencia del usuario.

Pero en caso de que necesites algún valor realmente personalizado para algún estilo en particular, puedes conseguirlo añadiendo un tema personalizado en la función tailwind.config.js. Por ejemplo, para obtener un shadow-3xl (Tailwind no proporciona shadow-3xl fuera de la caja) puede añadir las siguientes líneas en el archivo module.exports en tailwind.config.js:

module.exports = {
  theme: {
    extend: {
      boxShadow: {
        '3xl': '0 35px 60px -15px rgba(0, 0, 0, 0.3)',
      }
    }
  }
}

Y ahora, con la llegada del JIT, también puede utilizar un valor arbitrario entre corchetes [] como las siguientes:

<div class="shadow-[0_35px_60px_-15px_rgba(0,0,0,0.3)]">
  // Rest of your code goes here
</div>

El uso de valores arbitrarios puede ser útil cuando se necesita un estilo específico en solo unos pocos lugares. Y en este caso, crear un tema para ello en el archivo tailwind.config.js puede parecer innecesario.

Mi opinión

Realmente espero haber podido hacerte entender qué es Tailwind CSS y qué puedes hacer con él.

Tailwind es un framework CSS que nos proporciona clases de utilidad de un solo propósito que son opinables en su mayor parte, y que nos ayudan a diseñar nuestras páginas web desde dentro de nuestro marcado o archivos .js/.jsx/.ts/.tsx.

En mi opinión, Tailwind es sencillo y fácil de entender. Es cierto que puede llevar algún tiempo entender todos los nombres de las clases de utilidad, pero no te preocupes: puedes consultar su documentación siempre que te atasques.

Y para todos los principiantes que están empezando su andadura en el desarrollo web, es muy importante saber qué es CSS3 antes de explorar Tailwind (o cualquier otro framework CSS como Bootstrap, Windi CSS, etc.).

Conclusión

Gracias por leer. Espero que hayas disfrutado leyendo sobre Tailwind CSS en este artículo y que lo hayas encontrado útil.

Considera la posibilidad de compartirlo con tus amigos, te lo agradecería mucho. Sígueme en LinkedIn y Twitter (ver más abajo) y permanece atento a más contenidos increíbles. ¡Hasta la vista! ?

Enlace Social

Twitter

Kubernetes es una herramienta muy útil para los desarrolladores nativos de la nube. Pero no cubre todas las bases por sí sola: hay algunas cosas que Kubernetes no puede resolver o que están fuera de su alcance.

Esta es una de las razones por las que los proyectos de código abierto son tan fantásticos. Ayudan a que herramientas increíbles sean aún más increíbles cuando las combinamos con otras herramientas increíbles de código abierto. Y a menudo estas herramientas se desarrollaron con el único propósito de llenar los vacíos. Una de estas herramientas es Helm.

¿Qué es Helm?

Helm es ampliamente conocido como "el gestor de paquetes para Kubernetes". Aunque se presenta así, su alcance va mucho más allá del de un simple gestor de paquetes. Sin embargo, empecemos por el principio.

Helm es un proyecto de código abierto que fue creado originalmente por DeisLabs y donado a CNCF, que ahora lo mantiene. El objetivo original de Helm era proporcionar a los usuarios una forma mejor de gestionar todos los archivos YAML de Kubernetes que creamos en los proyectos de Kubernetes.

El camino que Helm tomó para resolver este problema fue crear Helm Charts. Cada gráfico es un paquete con uno o más manifiestos de Kubernetes: un gráfico puede tener gráficos hijos y gráficos dependientes.

Esto significa que Helm instala todo el árbol de dependencias de un proyecto si ejecuta el comando install para el gráfico de nivel superior. Sólo tiene que ejecutar un único comando para instalar toda su aplicación, en lugar de listar los ficheros a instalar mediante kubectl.

Charts también te permite versionar tus archivos de manifiesto, al igual que hacemos con Node.js o cualquier otro paquete. Esto te permite instalar versiones específicas de gráficos, lo que significa mantener configuraciones específicas para tu infraestructura en forma de código.

Helm también mantiene un historial de versiones de todas las cartas desplegadas, por lo que puede volver a una versión anterior si algo va mal.

Helm soporta Kubernetes de forma nativa, lo que significa que no tienes que escribir ningún archivo de sintaxis complejo ni nada para empezar a usar Helm. Solo tienes que soltar tus archivos de plantilla en un nuevo gráfico y listo.

Pero, ¿por qué deberíamos utilizarlo? La gestión de los manifiestos de aplicación puede hacerse fácilmente con unas pocas combinaciones de comandos.

¿Por qué utilizar Helm?

Helm realmente brilla donde Kubernetes no llegó. Por ejemplo, las plantillas. El alcance del proyecto Kubernetes es tratar con sus contenedores para usted, no sus archivos de plantilla.

Esto dificulta en exceso la creación de archivos realmente genéricos que puedan utilizarse en un equipo o una organización grandes, con muchos parámetros diferentes que deben configurarse para cada archivo.

Y también, ¿cómo versionar información sensible usando Git cuando los archivos de plantilla son texto plano?

La respuesta: Ir a las plantillas. Helm le permite añadir variables y utilizar funciones dentro de sus archivos de plantilla. Esto lo hace perfecto para aplicaciones escalables que eventualmente necesitarán cambiar sus parámetros. Veamos un ejemplo.

Tengo un proyecto de código abierto llamado Zaqar, un microservicio de correo electrónico simple para Node.js que se comunica con SendGrid. El proyecto se compone básicamente de un servicio, un despliegue y un autoescalador.

Tomemos como ejemplo el archivo de despliegue. Tendría algo como esto

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zaqar
  namespace: default
  labels:
    app: zaqar
    version: v1.0.0
    env: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: zaqar
      env: production
  template:
    metadata:
      labels:
        app: zaqar
        version: v1.0.0
        env: production
    spec:
      containers:
        - name: zaqar
          image: "khaosdoctor/zaqar:v1.0.0"
          imagePullPolicy: IfNotPresent
          env:
            - name: SENDGRID_APIKEY
              value: "MY_SECRET_KEY"
            - name: DEFAULT_FROM_ADDRESS
              value: "my@email.com"
            - name: DEFAULT_FROM_NAME
              value: "Lucas Santos"
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

Si quisiera usar esta plantilla en un CI pipeline, o publicarla en mi GitHub, necesitaría reemplazar las partes variables por marcadores de posición. Así que podemos reemplazar estos textos con la información requerida.

En este caso, tanto la etiqueta de versión como la etiqueta env y las variables de entorno se sustituirían por marcadores de posición, así:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zaqar
  namespace: default
  labels:
    app: zaqar
    version: #!VERSION!#
    env: #!ENV!#
spec:
  replicas: 1
  selector:
    matchLabels:
      app: zaqar
      env: #!ENV!#
  template:
    metadata:
      labels:
        app: zaqar
        version: #!VERSION!#
        env: #!ENV!#
    spec:
      containers:
        - name: zaqar
          image: "khaosdoctor/zaqar:#!VERSION!#"
          imagePullPolicy: IfNotPresent
          env:
            - name: SENDGRID_APIKEY
              value: "#!SENDGRID_KEY!#"
            - name: DEFAULT_FROM_ADDRESS
              value: "#!FROM_ADDR!#"
            - name: DEFAULT_FROM_NAME
              value: "#!FROM_NAME!#"
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 250m
              memory: 256Mi

Ahora podemos ejecutar nuestro CI pipeline. Pero antes de hacerlo, tenemos que reemplazar nuestros marcadores de posición con los valores reales.

Para ello podemos utilizar sed y su "super fácil" sed 's/#!PLACEHOLDER!#/replacement/g', y canalizar esto hacia abajo hasta que terminemos todos los marcadores de posición. El comando final sería algo como esto:

cat deploy.yaml | \
    sed 's/#!ENV!#/production/g' | \
    sed 's/#!VERSION!#/v1.0.0/g' | \
    sed 's/#!SENDGRID_KEY!#/MyKey/g' | \
    sed 's/#!FROM_ADDR!#/my@email.com/g' | \
    sed 's/#!FROM_NAME!#/Lucas Santos/g'

Por defecto, sed envía todo al archivostdout, para que podamos añadir otra tubería a kubectl -f, como <all the command from before> | kubectl -f -. Entonces tendremos nuestro despliegue en su lugar. El único problema es que tenemos que hacer lo mismo para todos los demás archivos.

Ahora imagina un proyecto más grande, con muchas otras variables y marcadores de posición. Probablemente, escribirías un script para hacerlo por ti, ¿verdad? Ese script es Helm.

Cuando se crea un Gráfico (más sobre esto más adelante), tenemos un árbol de directorios específico que debemos seguir para que Helm entienda lo que queremos hacer. Dentro del directorio templates podemos añadir nuestros archivos de manifiesto, con plantillas go nativas, de la siguiente manera:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
  namespace: {{ default .Release.Namespace .Values.namespace }}
  labels:
    app: {{ .Values.name }}
    version: {{ .Values.image.tag }}
    env: {{ .Values.env }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
      env: {{ .Values.env }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
        version: {{ .Values.image.tag }}
        env: {{ .Values.env }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "khaosdoctor/zaqar:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
            - name: SENDGRID_APIKEY
              value: {{ required "You must set a valid Sendgrid API key" .Values.environment.SENDGRID_APIKEY | quote }}
            - name: DEFAULT_FROM_ADDRESS
              value: {{ required "You must set a default from address" .Values.environment.DEFAULT_FROM_ADDRESS | quote }}
            - name: DEFAULT_FROM_NAME
              value: {{ required "You must set a default from name" .Values.environment.DEFAULT_FROM_NAME | quote }}
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Todos esos valores pueden obtenerse a partir de un archivo Values.yaml (para los valores por defecto), o puede configurarlos en la CLI utilizando el comando con su bandera --set <path> value.

Si queremos instalar nuestro gráfico podemos emitir el siguiente comando:

helm upgrade --install --create-namespace myChart ./path/to/my/chart \
  --set image.tag=v1.0.0 \
  --set env=production \
  --set environment.SENDGRID_APIKEY=myKey \
  --set environment.DEFAULT_FROM_ADDRESS="my@email.com" \
  --set environment.DEFAULT_FROM_NAME="Lucas Santos"

Helm también nos permite utilizar funciones dentro de nuestros despliegues. Así que podemos tener default para volver a los valores por defecto si no se rellenan, como el espacio de nombres. O podemos tener required que muestra un mensaje y no instala el gráfico si no se proporciona el valor, que es el caso de nuestras variables de entorno.

Hay muchas otras funciones útiles en sus documentos.

Ahora podemos no sólo gestionar de forma más eficiente los recursos de nuestra aplicación, sino también publicar estos recursos en un sistema de versiones de código abierto sin ningún tipo de molestia ni problema de seguridad.

Cómo crear un cuadro de mando

Es bastante fácil crear un gráfico en Helm. Primero, necesita tener Helm instalado. Luego, simplemente escriba helm create <chart name> y creará un directorio lleno de archivos y otros directorios. Esos archivos son necesarios para que Helm cree un gráfico.

Veamos con más detalle qué aspecto tiene este árbol de archivos y qué archivos contiene:

• chart.yaml: Aquí es donde pondrás la información relacionada con tu gráfico. Eso incluye la versión del gráfico, el nombre y la descripción para que puedas encontrarlo si lo publicas en un repositorio abierto. También en este archivo podrás establecer dependencias externas usando el comando dependencies llave.
• values.yaml: Como vimos antes, este es el archivo que contiene los valores por defecto para las variables.
• templates (dir): Este es el lugar donde pondrás todos tus archivos de manifiesto. Todo lo que haya aquí se transmitirá y creará en Kubernetes.
• charts:Si su gráfico depende de otro gráfico de su propiedad, o si no quiere depender de la biblioteca por defecto de Helm (el registro por defecto de donde Helm extrae los gráficos), puede traer esta misma estructura dentro de este directorio. Las dependencias de los gráficos se instalan de abajo a arriba, lo que significa que si el gráfico A depende del gráfico B, y B depende de C, el orden de instalación será C ->B ->A.

Hay otros campos, pero estos son los más comunes, y son los obligatorios. Puedes echar un vistazo rápido al repositorio de Zaqar para comprobar cómo podemos publicar gráficos de código abierto.

Una nota rápida: Cuando instale Helm, asegúrese de que está instalando la versión 3. La versión 2 todavía funciona. La versión 2 todavía funciona, pero necesita un componente del lado del servidor llamado Tiller, que ata su instalación helm a un solo clúster. Helm 3 eliminó esta necesidad con la adición de varios CRDs, pero no es compatible con todas las versiones de Kubernetes.

Cómo organizar un cuadro de mando

Vale, has creado tu gráfico, ¿y ahora qué? ¿Tenemos que descargar todo el repositorio para instalar esos gráficos? Helm tiene una biblioteca pública para los gráficos más utilizados, que funciona como Docker Hub.

También puede crear su propio repositorio de gráficos y alojarlo en línea. Helm bebe de la misma fuente que HomeBrew, o Linux. Puede acceder a estos repositorios para descargar los gráficos que contienen.

Dado que un repositorio de gráficos es básicamente un index.yaml servido desde un servidor web estático, prácticamente se puede crear un repositorio de gráficos desde cualquier lugar.

Por ejemplo, Zaqar está alojado en GitHub Pages y es accesible a través de mi dominio. Cuando Helm busca un index.yaml en realidad, está buscando la lista de versiones disponibles de ese gráfico, sus compendios SHA256 y la ubicación del archivo empaquetado .tgz para descargar el gráfico. Esto es más o menos lo que NPM hace bajo el capó (demasiado simplificado).

Esto significa que no necesitas tener tu repositorio clonado para siempre, y tus gráficos también pueden ser privados. Sólo necesitas crear un repositorio de gráficos.

Incluso puedes utilizar servicios alojados como Azure CR para hacer el trabajo, o puedes tener una solución completa llamada Chart Museum, que te permite almacenar tus gráficos y te proporciona una interfaz de usuario ordenada.

Conclusión

Helm está aquí para quedarse. Ha ayudado y ayudará a muchos desarrolladores de Kubernetes durante mucho tiempo.

Si quieres saber cómo usar Helm, puedes consultar su documentación, o puedes seguir este módulo de aprendizaje gratuito sobre cómo desplegar tus aplicaciones en Kubernetes de forma sencilla con Helm.

Otro gran lenguaje para añadir a tu cinturón de herramientas de desarrollador full-stack es el sencillo y productivo lenguaje de programación de propósito general Go.

Gracias a un proyecto iniciado en 2007, Go vio la luz gracias al esfuerzo de algunos programadores de Google. Pusieron mucho cuidado en el diseño de Go para que fuera claro y coherente en sus características de lenguaje y bibliotecas estándar, haciendo que Go fuera fácil y divertido de usar.

Es lo mejor del código abierto… pero no olvide que distingue entre mayúsculas y minúsculas.

Empecemos con el sistema operativo Microsoft Windows 10. Verás lo fácil que es en realidad - solo se requiere un conocimiento básico de GitHub y el símbolo del sistema. Seguro que hay otras maneras de instalar y ejecutar el programa, pero con un conocimiento limitado de codificación sentí que este conjunto de instrucciones era el más fácil de entender y seguir.

Asegúrese de seguir estos pasos en su totalidad, así como en el orden correcto (como se indica) para ahorrarse, tener que desinstalar Go y pasar unas cuantas horas solucionando cualquier problema relacionado con la instalación.

Fase 1: Instale lo siguiente en este orden

1. Como Go utiliza a menudo repositorios de código abierto (¡GRATUITOS!), asegúrate de instalar primero el paquete Git aquí.
2. Navegue hasta el sitio web de instalación de Go aquí. Descargue e instale la última versión de Go de 64 bits para el sistema operativo Microsoft Windows.
3. Siga las instrucciones del programa de instalación Go.
4. Ejecute el símbolo del sistema en su ordenador buscando "cmd". Abra la línea de comandos y escriba "go version"
5. La salida después de introducir la versión go debería tener este aspecto:

Fase 2: Creación del espacio de trabajo Go

En primer lugar, confirme sus binarios Go: vaya al Panel de control de su ordenador, luego a Sistema y seguridad > Sistema > Configuración avanzada del sistema y, en el panel de la izquierda, haga clic en la pestaña Avanzado. A continuación, haga clic en Variables de entorno en la parte inferior derecha. Asegúrese de que la variable "C:\Go\bin" está en la ruta de las variables del sistema.

A continuación, cree su espacio de trabajo Go. Esto será en una carpeta nueva y separada de donde se guardan los archivos de instalación de Go. Por ejemplo, sus archivos de instalación G se guardaron en la ruta C:\Go y usted está creando su espacio de trabajo Go en C:\Projects\Go

En tu nueva carpeta Go work-space, crea tres nuevas carpetas:

Fase 3: Crear la variable de entorno GOPATH

Crea la variable GOPATH y haz referencia a tu recién creado espacio de trabajo Go. Vuelve a tu Panel de Control y navega hasta Sistema y luego a Variables de Entorno. A continuación, en Variables del sistema, haga clic en Nuevo.

Junto a Nombre de variable, introduzca "GOPATH", y junto a Valor de variable introduzca "C:\Proyectos\Go".

Para comprobar que la ruta se ha establecido correctamente, introduzca "echo %GOPATH%" en la línea de comandos.

Fase 4: Probar y garantizar

Ahora estás listo para verificar que todo funciona correctamente abriendo la línea de comandos y escribiendo: go get github.com/golang/example/hello

Espere a que el código se ejecute por completo (puede tardar unos segundos) y, a continuación, introduzca lo siguiente en la línea de comandos: %GOPATH%/bin/hello

Si la instalación se ha realizado correctamente, debería recibir el siguiente mensaje de retorno: “Hello, Go examples!”

Espero que tenga éxito. Y si te encuentras con algún error o mensajes confusos, comentar a continuación con los resultados de esta línea de comandos: “go env”

¡Y ahora estás listo para convertirte en un "Gopher"!

Exploremos algunos conceptos básicos que nos ayudarán a crear una IA de ajedrez sencilla:

• move-generation
• board evaluation
• minimax
• and alpha beta pruning.

En cada paso, mejoraremos nuestro algoritmo con una de estas técnicas de programación de ajedrez probadas con el tiempo. Demostraré cómo afecta cada una de ellas al estilo de juego del algoritmo.

Puedes consultar el algoritmo final de IA aquí, en GitHub.

Paso 1: Generación de movimientos y visualización del tablero

Usaremos la librería chess.js para la generación de movimientos, y chessboard.js para visualizar el tablero. La librería de generación de movimientos básicamente implementa todas las reglas del ajedrez. Basándonos en esto, podemos calcular todos los movimientos legales para un estado dado del tablero.

El uso de estas bibliotecas nos ayudará a centrarnos solo en la tarea más interesante: crear el algoritmo que encuentre la mejor jugada.

Empezaremos creando una función que simplemente devuelva una jugada aleatoria de entre todas las posibles:

Aunque este algoritmo no es un jugador de ajedrez muy sólido, es un buen punto de partida, ya que podemos jugar contra él:

Paso 2: Evaluación de la posición

Ahora vamos a intentar comprender qué bando es más fuerte en una posición determinada. La forma más sencilla de conseguirlo es contar la fuerza relativa de las piezas en el tablero utilizando la siguiente tabla:

Con la función de evaluación, somos capaces de crear un algoritmo que elige el movimiento que da la evaluación más alta:

La única mejora tangible es que ahora nuestro algoritmo capturará una pieza si puede.

Paso 3: Árbol de búsqueda utilizando Minimax

A continuación vamos a crear un árbol de búsqueda a partir del cual el algoritmo pueda elegir la mejor jugada. Esto se hace mediante el algoritmo Minimax.

En este algoritmo, el árbol recursivo de todos los movimientos posibles se explora hasta una profundidad determinada, y la posición se evalúa en las "hojas" finales del árbol.

Después de eso, devolvemos el menor o el mayor valor del hijo al nodo padre, dependiendo de si es un blanco o un negro para mover. (Es decir, tratamos de minimizar o maximizar el resultado en cada nivel).

Con minimax en su lugar, nuestro algoritmo está empezando a entender algunas tácticas básicas del ajedrez:

La eficacia del algoritmo minimax se basa en gran medida en la profundidad de búsqueda que podamos alcanzar. Esto es algo que mejoraremos en el siguiente paso.

Paso 4: Poda alfa-beta

La poda alfa-beta es un método de optimización del algoritmo minimax que nos permite descartar algunas ramas del árbol de búsqueda. Esto nos ayuda a evaluar el árbol de búsqueda minimax mucho más profundamente, utilizando los mismos recursos.

La poda alfa-beta se basa en la situación en la que podemos dejar de evaluar una parte del árbol de búsqueda si encontramos un movimiento que conduce a una situación peor que un movimiento descubierto anteriormente.

La poda alfa-beta no influye en el resultado del algoritmo minimax, sólo lo hace más rápido.

El algoritmo alfa-beta también es más eficiente si visitamos primero los caminos que conducen a buenas jugadas.

Con alfa-beta, obtenemos una mejora significativa del algoritmo minimax, como se muestra en el siguiente ejemplo:

Sigue este enlace para probar la versión alfa-beta mejorada de la IA de ajedrez.

Paso 5: Mejora de la función de evaluación

La función de evaluación inicial es bastante ingenua, ya que sólo contamos el material que se encuentra en el tablero. Para mejorarla, añadimos a la evaluación un factor que tiene en cuenta la posición de las piezas. Por ejemplo, un caballo en el centro del tablero es mejor (porque tiene más opciones y, por tanto, es más activo) que un caballo en el borde del tablero.

Utilizaremos una versión ligeramente ajustada de las tablas pieza-cuadrado que se describen originalmente en chess-programming-wiki.

Con la siguiente mejora, empezamos a conseguir un algoritmo que juega algo de ajedrez "decente", al menos desde el punto de vista de un jugador ocasional:

Conclusiones

El punto fuerte de un algoritmo de ajedrez sencillo es que no comete errores estúpidos. Dicho esto, le sigue faltando comprensión estratégica.

Con los métodos que he introducido aquí, hemos sido capaces de programar un algoritmo de juego de ajedrez que puede jugar al ajedrez básico. La "parte IA" (excluyendo la generación de jugadas) del algoritmo final tiene sólo 200 líneas de código, lo que significa que los conceptos básicos son bastante sencillos de implementar. Puede consultar la versión final en GitHub.

Otras mejoras que podríamos introducir en el algoritmo serían, por ejemplo:

• move-ordering
• generación de movimientos más rápidos
• y la evaluación específica de los objetivos finales.

Si quieres aprender más, echa un vistazo a la wiki de programación de ajedrez. Es un recurso útil para explorar más allá de estos conceptos básicos que he introducido aquí.

Gracias por leerme.

Cuando comencé a aprender a probar mis aplicaciones en el pasado, me frustró mucho con los diferentes tipos, estilos y tecnologías utilizadas para las pruebas, junto con la variedad disuelta de publicaciones de blog, tutoriales y artículos. Descubrí que esto también es cierto para las pruebas de React.

Así que decidí escribir una guía completa de prueba de React en un artículo.

Guía completa, eh, ¿va a cubrir todos los escenarios de prueba posibles? Por supuesto que no. Sin embargo, será una guía básica completa para las pruebas y será suficiente para desarrollar la mayoría de los otros casos extremos.

También seleccioné una extensa colección de publicaciones de blog, artículos y tutoriales en la sección de lectura adicional al final que debería brindarle el conocimiento suficiente para estar en el 10% superior de los desarrolladores en términos de pruebas.

Puedes encontrar el proyecto terminado aquí:
https://github.com/iqbal125/react-hooks-testing-complete

tabla de contenido

teoría

• ¿Qué son los Test?
• ¿Por qué testear?
• ¿Qué testear?
• ¿Qué no testear?
• como Testeo
• Superficial vs Profundo
• unidad vs integracion vs eae

informacion preliminar

• algunas probabilidades y terminacion

enzima

• Configuración de Enyme
• renderizador de prueba de reaccion
• prueba de instantaneas
• probar los detalles de implementacion

Biblioteca de pruebas React

• useState y props
• usarReductor()
• useContext()
• Formularios de componentes controlados
• Solicitudes de API de useEffect() y Axios

Ciprés

• Una prueba completa de extremo a extremo

integracion continua

• Travis.yml
• Código Cobertura con overoles

teoria

¿Que es el Testin?

Comencemos por el principio y analicemos qué es la prueba. La prueba es un proceso de 3 pasos que se ve asi:

Arreglar, su aplicación está en un cierto estado original. Actúa, luego sucede algo (evento de clic, entrada, etc.). Luego afirma, o hace una hipótesis, del nuevo estado de su aplicación. Las pruebas pasarán si su hipótesis es correcta y fallarán si es incorrecta.

A diferencia de sus componentes de reacción, sus pruebas no se ejecutan en el navegador. Jest es el corredor de pruebas y el marco de prueba utilizado por React. Jest es el entorno donde se ejecuta realmente todas las pruebas. Es por eso que no necesita importar expecty describeen sus archivos. Estas funciones ya están disponibles globalmente en el entorno jest.

La sintaxis de sus pruebas se verá así:

describe('Testing sum', () => {
    function sum(a, b) {
       return a + b;
    }

    it('should equal 4',()=>{
       expect(sum(2,2)).toBe(4);
      })

    test('also should equal 4', () => {
        expect(sum(2,2)).toBe(4);
      }) 
});

describe envuelve nuestro bloque ito test, y es una forma de agrupar nuestras pruebas. Ambas ity testson palabras clave y se pueden usar indistintamente. La cadena será algo que debería suceder con sus pruebas y se imprimirá en la consola. toBe()es un comparador que funciona con esperar para permitirle hacer afirmaciones. Hay muchos más emparejadores y variables globales que ofrecemos broma, vea los enlaces a continuación para obtener una lista completa.

https://jestjs.io/docs/en/using-matchers

https://jestjs.io/docs/en/api

¿Qué testear?

Los test se realizan para garantizar que su aplicación funcione según lo previsto para sus usuarios finales. Tener pruebas hará que su aplicación sea más robusta y menos propensa a errores. Es una forma de verificar que el código está haciendo lo que pretendían los desarrolladores.

Posibles desventajas:

• La redacción de la prueba requiere mucho tiempo y es difícil.
• En ciertos escenarios, ejecutar test en CI puede costar dinero real.
• Si se hace incorrectamente, puede darte falsos positivos. Sus pruebas pasan, pero su aplicación no funciona según lo previsto.
• O falsos negativos. Sus pruebas fallan, pero su aplicación funciona según lo previsto.

¿Qué testear?

Para desarrollar el punto anterior, sus pruebas deben probar la funcionalidad de la aplicación, que imita cómo la usarán sus usuarios finales. Esto le dará la confianza de que su aplicación funcionará según lo previsto en su entorno de producción. Por supuesto, entraremos en muchos más detalles a lo largo de este artículo, pero esta es la esencia básica.

¿Qué no testear?

Me gusta usar la filosofía de Kent C dodds aquí de que no debe probar los detalles de implementación.

Detalles de implementación que significan probar cosas que no son la funcionalidad del usuario final. Veremos un ejemplo de esto en la sección Enzima a continuación.

Parece que está probando la funcionalidad allí, pero en realidad no es así. Estás probando el nombre de la función. Porque puede cambiar el nombre de la función y sus pruebas fallarán, pero su aplicación seguirá funcionando y le dará un falso negativo.

Tener que preocuparse constantemente por los nombres de funciones y variables es un dolor de cabeza, y tener que reescribir las pruebas cada vez que las cambia es tedioso, le mostraré un mejor enfoque.

Const variables: estas son variables que no cambian, no es necesario probarlas.

Bibliotecas de terceros: No es su trabajo probar estas bibliotecas. Depende de los creadores de estas bibliotecas probarlo. Si no está seguro de si una biblioteca está probada, no debe usarla. O puede leer el código fuente para ver si el autor incluye pruebas. Puede descargar el código fuente y ejecutar estas pruebas usted mismo. También puede preguntarle al autor si su biblioteca está lista para la producción o no.  

Mi filosofía personal sobre las pruebas

Gran parte de mi filosofía de evaluación se basa en las enseñanzas de Kent C dodds, por lo que verás muchos de sus sentimientos reflejados aquí, pero también algunos de mis propios pensamientos.

Muchas pruebas de integración. Sin pruebas instantáneas. Pocas pruebas unitarias. Pocas pruebas de ea e.

Las pruebas unitarias están un paso por encima de las pruebas instantáneas, pero no son ideales. Sin embargo, es mucho más fácil de entender y mantener que las pruebas instantáneas.

Escribir principalmente pruebas de integración. Las pruebas unitarias son buenas, pero en realidad no se parecen a la forma en que su usuario final interactúa con su aplicación. Es muy fácil probar los detalles de implementación con pruebas unitarias, especialmente con renderizado superficial.

Las pruebas de integración deben usarse lo menos posible

No se probaron detalles de implementación como nombres de funciones y variables.

Por ejemplo, si estamos probando un botón y cambiamos el nombre de la función en el método onClick de increment() a handleClick(), nuestras pruebas fallarían pero nuestro componente seguirá funcionando. Esta es una mala práctica porque básicamente solo estamos probando el nombre de la función, que es un detalle de implementación, que no le importa a nuestro usuario final.

Montaje superficial vs.

Mount en realidad ejecuta el código html, css y js como lo haría un navegador, pero lo hace de forma simulada. Es "sin cabeza", por ejemplo, lo que significa que no representa ni pinta nada en una interfaz de usuario, sino que actúa como un navegador web simulado y ejecuta el código en segundo plano.

No perder tiempo pintando nada en la interfaz de usuario hace que sus pruebas sean mucho más rápidas. Sin embargo, las pruebas de montaje siguen siendo mucho más lentas que las pruebas superficiales.

Esta es la razón por la que desmonta o limpia el componente después de cada prueba, porque es casi una aplicación en vivo y una prueba afectará a otra prueba.

Mount/render se usa normalmente para prueba de integración y superficial para prueba unitaria.

la renderización superficial solo renderiza el único componente que estamos probando. No renderiza componentes secundarios. Esto nos permite probar nuestro componente de forma aislada.

Por ejemplo, considere este componente hijo y padre.

import React from 'react';

const App = () => {
  return (
    <div> 
      <ChildComponent /> 
    </div> 
  )
}

const ChildComponent = () => {
  return (
    <div>
     <p> Child components</p>
    </div>
  )
}

Si usamos una representación superficial de App.jsobtendríamos algo como esto, observe que ninguno de los nodos DOM para el componente secundario está presente, de ahí el término representación superficial.

<App>
  <div> 
    <ChildComponent /> 
  </div>
</App> 

Ahora podemos comparar esto con el montaje del componente:

<App>
  <div> 
    <ChildComponent> 
      <div>
       <p> Child components</p>
      </div>
    </ChildComponent>
   </div>
</App> 

Lo que tenemos arriba está mucho más cerca de cómo se verá nuestra aplicación en el navegador, de ahí la superioridad de mount/render.

Unidad vs integración vs extremo a extremo

unit testing : probando una parte aislada de su aplicación, generalmente realizada en combinación con una representación superficial. Ejemplo: un componente se renderiza con los accesorios predeterminados.

pruebas de integración: probar si las diferentes partes funcionan o se integran entre sí. Por lo general, se realiza con el montaje o renderizado de un componente. Ejemplo: prueba si un componente secundario puede actualizar el estado del contexto en un componente principal.

e to e testing : significa "de extremo a extremo". Por lo general, una prueba de varios pasos que combina múltiples pruebas unitarias y de integración en una gran prueba. Por lo general, muy poco se burla o se critica. Las pruebas se realizan en un navegador simulado, puede haber o no una interfaz de usuario mientras se ejecuta la prueba. Ejemplo: probar un flujo de autenticación completo.

Informacion preliminar

react-testing-library: Personalmente, me gusta usar react-testing-library, pero la forma común es usar Enzyme. Le mostraré un ejemplo de Enzyme porque es importante conocer Enzyme en un nivel básico y el resto de los ejemplos con react-testing-library.

Esquema de ejemplos: Nuestros ejemplos seguirán un patrón. Primero le mostraré el componente React y luego las pruebas para él, con detalles detallados de cada uno. También puede seguir el repositorio vinculado al principio.

Configuración: También supondré que está utilizando create-react-app con la configuración de prueba predeterminada con jest, por lo que omitiré las configuraciones manuales.

Sinon, moca, chai: Gran parte de la funcionalidad que ofrece sinon está disponible de forma predeterminada con jest, por lo que no necesita sinon. Mocha y chai son un reemplazo para la broma. Jest viene preconfigurado de fábrica para funcionar con su aplicación, por lo que no tiene sentido usar Mocha y chai.

Esquema de nomenclatura de componentes: Mi esquema de nombres para los componentes es <TestSomething /> pero eso no significa que sean componentes falsos de ninguna manera. Son componentes regulares de React, este es solo el esquema de nombres.

npm test y jest watch mode :yarn test  trabajó para mi. npm testno funcionaba correctamente con el modo de reloj de broma.

probando un solo archivo : yarn test nombre del archivo

React Hooks vs Classes: Utilizo los componentes de React Hooks para la mayoría de los ejemplos, pero debido al poder de la biblioteca de pruebas de react, todas estas pruebas también funcionarán directamente con los componentes de la clase.

Con la información de fondo preliminar fuera del camino, podemos reparar algo de código.

enzima

Configuración de enzimas

Nuestras bibliotecas de terceros

npm install enzyme enzyme-to-json  enzyme-adapter-react-16

Comenzamos primero con nuestras importaciones.

import React from 'react';
import ReactDOM from 'react-dom';
import Basic from '../basic_test';

import Enzyme, { shallow, render, mount } from 'enzyme';
import toJson from 'enzyme-to-json';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() })

Comenzaremos con nuestras importaciones básicas. Nuestras primeras 3 importaciones son para reaccionar y nuestros componentes.

Después de esto importamos Enzyme. Luego importamos la función toJson de la biblioteca 'enzyme-to-json'. Necesitaremos esto para convertir nuestros componentes renderizados poco profundos en JSON, que se pueden guardar en el archivo de forma instantánea.

Finalmente, importamos nuestro Adaptador para hacer que la enzima funcione con React 16 y lo inicializamos como se muestra arriba.

react-test-renderer

React en realidad viene con su propio renderizador de prueba que puede usar en lugar de enzima y la sintaxis se verá así.

// import TestRenderer from 'react-test-renderer';
// import ShallowRenderer from 'react-test-renderer/shallow';


// Basic Test with React-test-renderer
// it('renders correctly react-test-renderer', () => {
//   const renderer = new ShallowRenderer();
//   renderer.render(<Basic />);
//   const result = renderer.getRenderOutput();
//
//   expect(result).toMatchSnapshot();
// });

Pero incluso los documentos de react-test-render sugieren usar enzima en su lugar porque tiene una sintaxis un poco más agradable y hace lo mismo. Sólo algo a tener en cuenta.

Prueba de instantaneas

Ahora nuestra primera prueba, que es una prueba instantánea.

it('renders correctly enzyme', () => {
  const wrapper = shallow(<Basic />)

  expect(toJson(wrapper)).toMatchSnapshot();
});

Si no ha ejecutado este comando antes, se creará automáticamente una carpeta _snapshots_ y un archivo test.js.snap. En cada prueba posterior, la nueva instantánea se comparará con el archivo de instantánea existente. La prueba pasará si la instantánea no ha cambiado y fallará si ha cambiado.

Básicamente, las pruebas instantáneas le permiten ver cómo ha cambiado su componente desde la última prueba, línea por línea. Las líneas de código que han cambiado se conocen como diff.

Aquí está nuestro componente básico que estamos probando instantáneas:

import React from 'react';


const Basic = () => {
  return (
    <div >
      <h1> Basic Test</h1>
         <p> This is a basic Test Component</p>
    </div>
  );
}

export default Basic;

Ejecutar la prueba anterior generará un archivo que se verá así. Este es esencialmente nuestro árbol de nodos React DOM.

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`renders correctly enzyme 1`] = `
<div>
  <h1>
     Basic Test
  </h1>
  <p>
     This is a basic Test Component
  </p>
</div>
`;

Y producirá una estructura de carpetas que se verá así:

La salida de tu terminal se verá así:

Sin embargo, ¿qué sucede si cambiamos nuestro componente básico a este

import React from 'react';


const Basic = () => {
  return (
    <div >
      <h1> Basic Test</h1>

    </div>
  );
}

export default Basic;

Nuestras instantáneas ahora fallarán

Y también nos dará la diferencia.

Al igual que en git, el "-" antes de cada línea significa que se eliminó.

Solo necesitamos presionar "w" para activar el modo reloj y luego presionar "u" para actualizar la instantánea.

Nuestro archivo de instantáneas se actualizará automáticamente con la nueva instantánea y pasará nuestras pruebas

// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`renders correctly enzyme 1`] = `
<div>
  <h1>
     Basic Test
  </h1>
</div>
`;

Esto es solo para pruebas de instantáneas, pero si lees mi sección de pensamientos personales, sabes que no hago pruebas de instantáneas. Lo incluí aquí porque, al igual que Enzyme, es muy común y es algo que debe tener en cuenta, pero a continuación intentaré explicar por qué no lo uso.

Repasemos de nuevo qué es la prueba de instantáneas. Básicamente, le permite ver cómo ha cambiado su componente desde la última prueba. Cuáles son los beneficios de esto.

• Es muy rápido y fácil de implementar y, a veces, solo requiere unas pocas líneas de código.
• Puedes ver si nuestro componente se está renderizando correctamente. Puedes ver claramente los nodos DOM con la función .debug().

Contras, Argumentos en contra de las pruebas de instantáneas:

• Lo único que hace una prueba instantánea es decirle si la sintaxis de su código ha cambiado desde la última prueba.
• Entonces, ¿qué es lo que realmente está probando? Algunos dirían que no mucho.
• También la representación básica de la aplicación correctamente es el trabajo de React, por lo que vas a probar un territorio de biblioteca de terceros.
• También se pueden comparar diferencias con el control de versiones de git. Este no debería ser el trabajo de las pruebas de instantáneas.
• Una prueba fallida no significa que su aplicación no esté funcionando según lo previsto, solo que su código ha cambiado desde la última vez que ejecutó la prueba. Esto puede generar muchos falsos negativos y una falta de confianza en la prueba. Esto también puede llevar a que las personas simplemente actualicen la prueba sin mirarla demasiado de cerca.
• La prueba de instantáneas también le dice si su JSX es sintácticamente correcto, pero nuevamente, esto se puede hacer fácilmente en el entorno de desarrollo. Ejecutar una prueba de instantánea solo para verificar los errores de sintaxis no tiene ningún sentido.
• Puede ser difícil entender lo que sucede en una prueba de instantáneas, ya que la mayoría de las personas usan pruebas de instantáneas con renderizado superficial, que no renderiza componentes secundarios, por lo que no le da al desarrollador ningún conocimiento.

Consulta la sección de lectura adicional para obtener más información.

Probando los detalles de implementación con Enzyme

Aquí daré un ejemplo de por qué no probar los detalles de implementación. Digamos que tenemos un componente de contador simple así:

import React, { Component } from 'react';


class Counter extends Component {
  constructor(props) {
    super(props)

    this.state = {
      count: 0
    }
  }

  increment = () => {
    this.setState({count: this.state.count + 1})
  }

  //This incorrect code will still cause tests to pass
  // <button onClick={this.incremen}>
  //   Clicked: {this.state.count}
  // </button>

  render() {
    return (
      <div>
        <button className="counter-button" onClick={this.incremen}>
          Clicked: {this.state.count}
        </button>
      </div>
  )}
}

export default Counter;

Notarás que tengo un comentario que sugiere que una aplicación que no funciona hará que las pruebas pasen, por ejemplo, al escribir mal el nombre de la función en el evento onClick.

Y veamos las pruebas que dejarán claro por qué.

import React from 'react';
import ReactDOM from 'react-dom';
import Counter from '../counter';

import Enzyme, { shallow, render, mount } from 'enzyme';
import toJson from 'enzyme-to-json';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() })

// incorrect function assignment in the onClick method
// will still pass the tests.

test('the increment method increments count', () => {
  const wrapper = mount(<Counter />)

  expect(wrapper.instance().state.count).toBe(0)

  // wrapper.find('button.counter-button').simulate('click')
  // wrapper.setState({count: 1})
  wrapper.instance().increment()
  expect(wrapper.instance().state.count).toBe(1)
})

Ejecutando el código anterior pasará las pruebas. También lo hará el uso wrapper.setState(). Así que tenemos pruebas de aprobación con una aplicación no funcional. No sé sobre usted, pero esto no me da confianza de que nuestra aplicación funcionará según lo previsto para nuestros usuarios finales.

Simular hacer clic en el botón no pasará las pruebas, pero podría darnos el problema opuesto, un falso negativo. Digamos que queremos cambiar el estilo del botón declarando una nueva clase CSS para él, una situación muy común. Nuestras pruebas ahora fallarán porque ya no podemos encontrar nuestro botón, pero nuestra aplicación seguirá funcionando, dándonos un falso negativo. Esto también es cierto cada vez que cambiamos los nombres de nuestras funciones o variables de estado.

Cada vez que queremos cambiar nuestra función y los nombres de clase CSS tenemos que reescribir nuestras pruebas, un proceso muy ineficiente y tedioso.

Entonces, ¿qué podemos hacer en su lugar?

React-testing-library

useState

De los documentos de la biblioteca de pruebas de react vemos que el principio rector principal es

Cuanto más se parezcan sus pruebas a la forma en que se usa su software, más confianza le pueden brindar.

Tendremos en cuenta este principio rector a medida que exploremos más con nuestras pruebas.

Comencemos con un componente básico de React Hooks y probemos el estado y las propiedades.

import React, { useState } from 'react';


const TestHook = (props) => {
  const [state, setState] = useState("Initial State")

  const changeState = () => {
    setState("Initial State Changed")
  }

  const changeNameToSteve = () => {
    props.changeName()
  }

  return (
  <div>
    <button onClick={changeState}>
      State Change Button
    </button>
    <p>{state}</p>
    <button onClick={changeNameToSteve}>
       Change Name
    </button>
    <p>{props.name}</p>
  </div>
  )
}


export default TestHook;

Nuestros accesorios provienen del componente principal root

  const App = () => {
      const [state, setState] = useState("Some Text")
      const [name, setName] = useState("Moe")
  ...
      const changeName = () => {
        setName("Steve")
      }

      return (
        <div className="App">
         <Basic />
        <h1> Counter </h1>
         <Counter />
        <h1> Basic Hook useState </h1>
         <TestHook name={name} changeName={changeName}/>
    ...     

Entonces, teniendo en cuenta nuestro principio rector, ¿cómo serán nuestras pruebas?

La forma en que nuestro usuario final usará esta aplicación será: ver un texto en la interfaz de usuario, ver el texto en el botón, luego hacer clic en él, finalmente ver un texto nuevo en la interfaz de usuario.

Así es como escribiremos nuestras pruebas usando la biblioteca de pruebas de React.

Utiliza este comando para instalar la biblioteca de pruebas de react.

npm install @testing-library/react

no

npm install react-testing-library

Ahora para nuestras pruebas

import React from 'react';
import ReactDOM from 'react-dom';
import TestHook from '../test_hook.js';
import {render, fireEvent, cleanup} from '@testing-library/react';
import App from '../../../App'

afterEach(cleanup)

it('Text in state is changed when button clicked', () => {
    const { getByText } = render(<TestHook />);

    expect(getByText(/Initial/i).textContent).toBe("Initial State")

    fireEvent.click(getByText("State Change Button"))

    expect(getByText(/Initial/i).textContent).toBe("Initial State Changed")
 })


it('button click changes props', () => {
  const { getByText } = render(<App>
                                <TestHook />
                               </App>)

  expect(getByText(/Moe/i).textContent).toBe("Moe")

  fireEvent.click(getByText("Change Name"))

  expect(getByText(/Steve/i).textContent).toBe("Steve")
})

Primero comenzamos con nuestras importaciones habituales.

A continuación tenemos la funcion afterEach(cleanup). Dado que no estamos usando renderizado superficial, tenemos que desmontar o limpiar después de cada prueba. Y esto es exactamente lo que está haciendo esta función.

getByText es el método de consulta que obtenemos al usar la desestructuración de objetos en el valor de la función de representación. Hay varios métodos de consulta más, pero este es el que querrá usar la mayor parte del tiempo.

Para probar nuestro aviso de estado, no estamos usando ningún nombre de función o los nombres de nuestras variables de estado. Mantenemos nuestro principio rector y no probamos los detalles de implementación. Dado que un usuario verá el texto en la interfaz de usuario, así es como consultaremos los nodos DOM. También consultaremos el botón de esta manera y haremos clic en él. Finalmente, también consultaremos el estado final en función del texto.

(/Initial/i) es una expresión regular que devuelve el primer nodo que al menos contiene el texto "Inicial".

es una expresión regular que devuelve el primer nodo que al menos contiene el texto "Inicial". App.js necesitaremos renderizarlo junto con nuestro componente. Al igual que en el ejemplo anterior, no estamos usando nombres de funciones y variables. Estamos probando la misma forma en que un usuario usaría nuestra aplicación y es a través del texto que verá.

Esperemos que esto le dé una buena idea de cómo probar con el react-testing-library y el principio rector, por lo general desea utilizar getByText la mayor parte del tiempo Hay algunas excepciones que veremos a medida que avancemos.

useReducer

Ahora podemos probar un componente con el gancho useReducer. Por supuesto, necesitaremos acciones y reductores para trabajar con nuestro componente, así que configurémoslos así:

Nuestra reductor

import * as ACTIONS from './actions'

export const initialState = {
    stateprop1: false,
}

export const Reducer1 = (state = initialState, action) => {
  switch(action.type) {
    case "SUCCESS":
      return {
        ...state,
        stateprop1: true,
      }
    case "FAILURE":
      return {
        ...state,
        stateprop1: false,
      }
    default:
      return state
  }
}

Y las acciones:

export const SUCCESS = {
  type: 'SUCCESS'
}

export const FAILURE = {
  type: 'FAILURE'
}

mantendremos las cosas simples y usaremos acciones en lugar de creadores de acciones.

Y finalmente el componente que utilizará estas acciones y reductores:

import React, { useReducer } from 'react';
import * as ACTIONS from '../store/actions'
import * as Reducer from '../store/reducer'


const TestHookReducer = () => {
  const [reducerState, dispatch] = useReducer(Reducer.Reducer1, Reducer.initialState)

  const dispatchActionSuccess = () => {
    dispatch(ACTIONS.SUCCESS)
  }

  const dispatchActionFailure = () => {
    dispatch(ACTIONS.FAILURE)
  }


  return (
    <div>
       <div>
        {reducerState.stateprop1
           ? <p>stateprop1 is true</p>
           : <p>stateprop1 is false</p>}
       </div>
       <button onClick={dispatchActionSuccess}>
         Dispatch Success
       </button>
    </div>
  )
}


export default TestHookReducer;

Este es un componente simple que cambiará stateprop1 De falsa a verdadera mediante el envío de una accio SUCCESS.

Y ahora nuestra prueba.

import React from 'react';
import ReactDOM from 'react-dom';
import TestHookReducer from '../test_hook_reducer.js';
import {render, fireEvent, cleanup} from '@testing-library/react';
import * as Reducer from '../../store/reducer';
import * as ACTIONS from '../../store/actions';


afterEach(cleanup)

describe('test the reducer and actions', () => {
  it('should return the initial state', () => {
    expect(Reducer.initialState).toEqual({ stateprop1: false })
  })

  it('should change stateprop1 from false to true', () => {
    expect(Reducer.Reducer1(Reducer.initialState, ACTIONS.SUCCESS ))
      .toEqual({ stateprop1: true  })
  })
})

it('Reducer changes stateprop1 from false to true', () => {
   const { container, getByText } = render(<TestHookReducer />);

   expect(getByText(/stateprop1 is/i).textContent).toBe("stateprop1 is false")

   fireEvent.click(getByText("Dispatch Success"))

   expect(getByText(/stateprop1 is/i).textContent).toBe("stateprop1 is true")
})

Primero comenzamos probando nuestro reductor. Y podemos envolver las pruebas para el reductor en el bloque describe. Estas son pruebas bastante básicas que estamos usando para asegurarnos de que initial state es lo que queremos y las acciones producen el resultado que queremos.

Puede argumentar que probar el reductor es probar los detalles de implementación, pero en la práctica descubrí que probar acciones y reductores es una prueba unitaria que siempre es necesaria.

Este es un ejemplo simple, por lo que no parece ser un gran problema, pero en aplicaciones más grandes y complejas, no probar los reductores y las acciones puede resultar desastroso. Por lo tanto, las acciones y los reductores serían una excepción a la regla de detalles de implementación de prueba.

A continuación tenemos nuestras pruebas para el componente real. Observe nuevamente que aquí no estamos probando los detalles de implementación. Usamos el mismo patrón del ejemplo anterior de useState. Obtenemos nuestros nodos DOM por el texto y también encontramos y hacemos clic en el botón con el texto.

useContext

Ahora avancemos y probemos si un componente secundario puede actualizar el estado del contexto en un componente principal. Esto puede parecer complejo, pero es bastante simple y directo.

Primero necesitaremos nuestro objeto de contexto que podemos inicializar en su propio archivo.

import React from 'react';

const Context = React.createContext()

export default Context

También necesitamos nuestro componente de aplicación principal que contendrá el proveedor de contexto. El valor transmitido al Provider será el valor del estado y de la función setState  del componente App.js.

import React, { useState } from 'react';
import TestHookContext from './components/react-testing-lib/test_hook_context';


import Context from './components/store/context';


const App = () => {
  const [state, setState] = useState("Some Text")
  

  const changeText = () => {
    setState("Some Other Text")
  }


  return (
    <div className="App">
    <h1> Basic Hook useContext</h1>
     <Context.Provider value={{changeTextProp: changeText,
                               stateProp: state
                                 }} >
        <TestHookContext />
     </Context.Provider>
    </div>
  );
}

export default App;

Y para nuestro componente

import React, { useContext } from 'react';

import Context from '../store/context';

const TestHookContext = () => {
  const context = useContext(Context)

  return (
    <div>
    <button onClick={context.changeTextProp}>
        Change Text
    </button>
      <p>{context.stateProp}</p>
    </div>
  )
}


export default TestHookContext;

Tenemos un componente simple que muestra el texto que inicializamos en App.js Y también pasamos la funcion setState del metodo onClick.

Nota: El estado es cambiado, inicializado y contenido en nuestro componente App.js.Simplemente hemos pasado el valor del estado y la funciób setState a nuestro componente secundario a través del contexto, pero en última instancia, el estado se maneja en el componente App.js. Esto será importante para entender nuestra prueba.

Y nuestra prueba:

import React from 'react';
import ReactDOM from 'react-dom';
import TestHookContext from '../test_hook_context.js';
import {act, render, fireEvent, cleanup} from '@testing-library/react';
import App from '../../../App'

import Context from '../../store/context';

afterEach(cleanup)

it('Context value is updated by child component', () => {

   const { container, getByText } = render(<App>
                                            <Context.Provider>
                                             <TestHookContext />
                                            </Context.Provider>
                                           </App>);

   expect(getByText(/Some/i).textContent).toBe("Some Text")

   fireEvent.click(getByText("Change Text"))

   expect(getByText(/Some/i).textContent).toBe("Some Other Text")
})

Incluso para el contexto, puedes ver que no rompemos nuestro patrón de pruebas, aún encontramos y simulamos nuestros eventos con el texto.

He incluido los componentes <Context.Provider/> y <TestHookContext /> en la función de representación porque hace que el código sea más fácil de leer, pero en realidad no necesitamos ninguno de ellos. Nuestra prueba seguirá funcionando si aprobamos solo el componente <App /> a la función de renderizado.

const { container, getByText } = render(<App/>) 

¿Por qué es este el caso?

Pensemos en lo que sabemos sobre el contexto. Todo el estado del contexto se maneja en App.js, por esta razón, este es el componente principal que estamos probando, aunque parece que estamos probando el componente secundario que usa el Hook useContext. Este código también funciona debido a mount/render. Como sabemos, en el renderizado superficial, los componentes secundarios son not rendered, pero son en mount/render. Ya que <Context.Provider /> y <TestHookContext /> ambos son componentes secundarios de <App /> se procesan automáticamente.

Formularios de componentes controlados

Un formulario de componente controlado esencialmente significa que el formulario funcionará a través del estado React en lugar de que el formulario mantenga su propio estado. Lo que significa que el controlador onChange guardará el texto de entrada en el estado React en cada pulsación de tecla.

Probar el formulario será un poco diferente de lo que hemos visto hasta ahora, pero intentaremos mantener nuestro principio rector en mente.

import React, { useState } from 'react';

const HooksForm1 = () => {
  const [valueChange, setValueChange] = useState('')
  const [valueSubmit, setValueSubmit] = useState('')

  const handleChange = (event) => (
    setValueChange(event.target.value)
  );

  const handleSubmit = (event) => {
    event.preventDefault();
    setValueSubmit(event.target.text1.value)
  };

    return (
      <div>
       <h1> React Hooks Form </h1>
        <form data-testid="form" onSubmit={handleSubmit}>
          <label htmlFor="text1">Input Text:</label>
          <input id="text1" onChange={handleChange} type="text" />
          <button type="submit">Submit</button>
        </form>
        <h3>React State:</h3>
          <p>Change: {valueChange}</p>
          <p>Submit Value: {valueSubmit}</p>
        <br />
      </div>
    )
}


export default HooksForm1;

Este es un formulario básico que tenemos aquí y también mostramos el valor del cambio y el valor de envío en nuestro JSX. Tenemos el atributo data-testid="form"  que usaremos en nuestra prueba para la consulta del formulario.

Y nuestras pruebas:

import React from 'react';
import ReactDOM from 'react-dom';
import HooksForm1 from '../test_hook_form.js';
import {render, fireEvent, cleanup} from '@testing-library/react';

afterEach(cleanup)

//testing a controlled component form.
it('Inputing text updates the state', () => {
    const { getByText, getByLabelText } = render(<HooksForm1 />);

    expect(getByText(/Change/i).textContent).toBe("Change: ")

    fireEvent.change(getByLabelText("Input Text:"), {target: {value: 'Text' } } )

    expect(getByText(/Change/i).textContent).not.toBe("Change: ")
 })


 it('submiting a form works correctly', () => {
     const { getByTestId, getByText } = render(<HooksForm1 />);

     expect(getByText(/Submit Value/i).textContent).toBe("Submit Value: ")

     fireEvent.submit(getByTestId("form"), {target: {text1: {value: 'Text' } } })

     expect(getByText(/Submit Value/i).textContent).not.toBe("Submit Value: ")
  })

Dado que un elemento de entrada vacío no tiene texto, usaremos una función getByLabelText() para obtener el nodo de entrada. Esto aún se mantendrá con nuestro principio rector, ya que el texto de la etiqueta es lo que el usuario leerá antes de ingresar el texto.

Ten en cuenta que activaremos el evento .change() en lugar del evento habitual .click() También pasamos datos ficticios en forma de:

{ target: { value: "Text" } }

Dado que se accederá al valor del formulario en forma de event.target.value,esto es lo que le pasamos al evento simulado.

Dado que generalmente no sabremos cuál es el texto que enviará el usuario, podemos usar una palabra clave .not para asegurarnos de que el texto haya cambiado en nuestro método de representación.

Podemos probar el envío del formulario de manera similar. La única diferencia es que usamos el evento .submit() y pasamos datos ficticios de esta manera:

{ target: { text1: { value: 'Text' } } }

Así es como se accede a los datos del formulario desde el evento sintético cuando un usuario envía un formulario. donde text1  es el id de nuestro elemento de entrada. Tendremos que romper nuestro patrón un poco aquí y usar el atributo data-testid="form" para consultar el formulario, ya que realmente no hay otra forma de obtener el formulario.

Y eso es todo por la forma. No es tan diferente de nuestros otros ejemplos. Si crees que lo entendiste, pasemos a algo un poco más complejo.

useEffect y solicitudes de API con axios

Ahora veamos cómo probaríamos el enlace useEffect hook y las solicitudes de API. sto será bastante diferente a lo que hemos visto hasta ahora.

Digamos que tenemos una URL pasada a un componente secundario desde el padre raíz.

...

     <TestAxios url='https://jsonplaceholder.typicode.com/posts/1' />
     
 ... 

Y el componente en sí.

import React, { useState, useEffect } from 'react';
import axios from 'axios';


const TestAxios = (props) => {
  const [state, setState] = useState()

  useEffect(() => {
    axios.get(props.url)
      .then(res => setState(res.data))
  }, [])


  return (
    <div>
    <h1> Axios Test </h1>
        {state
          ? <p data-testid="title">{state.title}</p>
          : <p>...Loading</p>}
    </div>
  )
}


export default TestAxios;

Simplemente hacemos una solicitud de API y guardamos los resultados en el estado local. También usamos una expresión ternaria en nuestro método de representación para esperar hasta que se complete la solicitud para mostrar los datos del título del marcador de posición json.

Notarás que nuevamente tendremos que hacer uso del atributo data-testid por necesidad, y nuevamente es un detalle de implementación ya que un usuario no verá ni interactuará con este atributo de ninguna manera, pero esto es más realista, ya que generalmente no conocerá el texto de una solicitud API de antemano.

También usaremos simulacros en esta prueba.

Un mock es una forma de simular un comportamiento que en realidad no queremos hacer en nuestras pruebas. Por ejemplo, nos burlamos de las solicitudes de API porque no queremos realizar solicitudes reales en nuestras pruebas.

No queremos realizar solicitudes de API reales en nuestras pruebas por varias razones: hará que nuestras pruebas sean mucho más lentas, podría darnos un falso negativo, la solicitud de API nos costará dinero o estropearemos nuestra base de datos con datos de prueba.

import React from 'react';
import ReactDOM from 'react-dom';
import TestAxios from '../test_axios.js';
import {act, render, fireEvent, cleanup, waitForElement} from '@testing-library/react';

import axiosMock from "axios";

Tenemos nuestras importaciones habituales pero notarás algo peculiar. Estamos importando axiosMock de la biblioteca axios. No estamos importando un objeto axios simulado de la biblioteca. En realidad, nos estamos burlando de la propia biblioteca de axios.

¿Cómo?

Mediante el uso de la funcionalidad de burla que ofrece jest.

Primero crearemos una __mocks__ adyacente a nuestra carpeta de prueba, algo como esto.

Y dentro de la carpeta de simulacros tenemos un archivo axios.js y esta es nuestra biblioteca axios falsa. Y dentro de nuestra biblioteca de axios falsos tenemos nuestra función simulacro de broma.

Las funciones simuladas nos permiten usar funciones en nuestro entorno de broma sin tener que implementar la lógica real de la función.

Básicamente, no vamos a implementar la lógica real detrás de una solicitud de obtención de axios. Solo usaremos esta función simulada en su lugar.

export default {
  get: jest.fn(() => Promise.resolve({ data: {} }) )
};

Aquí tenemos nuestra función de obtención falsa. Es una función simple que en realidad es un objeto JS. get es nuestra clave y el valor es la mock function. Como una solicitud de API de axios, resolvemos una promesa. No pasaremos ningún dato aquí, lo haremos en nuestra configuración de prueba.

Ahora nuestra configuración de prueba

//imports
...

afterEach(cleanup)

it('Async axios request works', async () => {
  axiosMock.get.mockResolvedValue({data: { title: 'some title' } })

  const url = 'https://jsonplaceholder.typicode.com/posts/1'
  const { getByText, getByTestId, rerender } = render(<TestAxios url={url} />);

  expect(getByText(/...Loading/i).textContent).toBe("...Loading")

  const resolvedEl = await waitForElement(() => getByTestId("title"));

  expect((resolvedEl).textContent).toBe("some title")

  expect(axiosMock.get).toHaveBeenCalledTimes(1);
  expect(axiosMock.get).toHaveBeenCalledWith(url);
 })

Lo primero que hacemos en nuestra prueba es llamar a nuestra falsa axios get request, y simular el valor resuelto con la función mockResolvedValue que ofrece jest. Esta función hace exactamente lo que dice su nombre, resuelve una promesa con los datos que le pasamos, lo que simula lo que hace axios.

Esta función debe llamarse antes de nuestra función render(), de lo contrario, la prueba no funcionará. Porque recuerda que nos estamos burlando de la propia biblioteca de axios. Cuando nuestro componente ejecuta la importación axios desde 'axios'; comando import axios from 'axios'; falsa en lugar de la real y esta axios falsa se sustituirá en nuestro componente donde sea que usemos axios.

A continuación, obtenemos nuestro nodo de texto "...Loading", ya que esto es lo que se mostrará antes de que se resuelva la promesa. Después de esto, tenemos una función que no hemos visto antes, la función waitForElement(), que esperará hasta que se resuelva la promesa antes de pasar a la siguiente afirmación.

Observa también las palabras clave await y async, que se usan exactamente de la misma manera que se usan en un entorno que no es de prueba.

Una vez resuelto, el nodo DOM tendrá el texto de "algún título", que son los datos que pasamos a nuestra biblioteca falsa de axios.

A continuación, nos aseguramos de que la solicitud solo se haya llamado una vez y con la URL correcta. Aunque estamos probando la URL, no hicimos una solicitud de API con esta URL.

Y esto es todo para las solicitudes de API con axios. En la siguiente sección veremos las pruebas e a e con ciprés.

Cypress

Ahora repasemos Cypress, que creo que es el mejor marco para ejecutar pruebas de e a e. Ahora estamos más tiempo en la tierra de las bromas, ahora trabajaremos únicamente con cypress, que tiene su propio entorno de prueba y sintaxis.

Cypress es bastante sorprendente y poderoso. De hecho, es tan asombroso y poderoso que podemos ejecutar todas las pruebas que acabamos de revisar en un bloque de prueba y ver cómo Cypress ejecuta estas pruebas en tiempo real en un navegador simulado.

Muy bien, ¿eh?

Creo que sí. De todos modos, antes de que podamos hacer eso, necesitamos configurar Cypress. Sorprendentemente, Cypress se puede instalar como un módulo npm normal.

npm install cypress

Para ejecutar cypress necesitará usar este comando.

node_modules/.bin/cypress open

Si eso parece engorroso de escribir cada vez que desee abrir cypress, puede agregarlo a su paquete.json.

...

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "cypress": "node_modules/.bin/cypress open", 
    
   ...

Esto le permitirá abrir cypress con solo el comando npm run cypress.

Abrir cypress te dará una GUI que se ve así.

Para ejecutar realmente las pruebas de Cypress, su aplicación deberá estar ejecutándose al mismo tiempo, lo que veremos en un segundo.

Ejecutar el comando cypress open le dará una configuración básica de cypress y creará algunos archivos y carpetas automáticamente. Se creará una carpeta Cypress en la raíz del proyecto. Escribiremos nuestro código en la carpeta de integración.

Podemos comenzar eliminando la carpeta de ejemplos. A diferencia de jest, los archivos de ciprés tienen una extensión .spec.js. Debido a que esta es una prueba de e a e, la ejecutaremos en nuestro archivo  App.js principal. Entonces debería tener una estructura de directorios que ahora se ve así.

También podemos establecer una URL base en el archivo cypress.json. Así como esto:

{ "baseUrl": "http://localhost:3000" }

Ahora para nuestra gran prueba monolítica

import React from 'react';

describe ('complete e to e test', () => {
  it('e to e test', () => {
    cy.visit('/')
    //counter test
    cy.contains("Clicked: 0")
      .click()
    cy.contains("Clicked: 1")
    // basic hooks test
    cy.contains("Initial State")
    cy.contains("State Change Button")
      .click()
    cy.contains("Initial State Changed")
    cy.contains("Moe")
    cy.contains("Change Name")
      .click()
    cy.contains("Steve")
    //useReducer test
    cy.contains('stateprop1 is false')
    cy.contains('Dispatch Success')
      .click()
    cy.contains('stateprop1 is true')
    //useContext test
    cy.contains("Some Text")
    cy.contains('Change Text')
      .click()
    cy.contains("Some Other Text")
    //form test
    cy.get('#text1')
      .type('New Text {enter}')
    cy.contains("Change: New Text")
    cy.contains("Submit Value: New Text")
    //axios test
    cy.request('https://jsonplaceholder.typicode.com/posts/1')
      .should(res => {
          expect(res.body).not.to.be.null
          cy.contains(res.body.title)
        })
  });
});

Como se mencionó, estamos ejecutando todas las pruebas que acabamos de revisar en un bloque de prueba. He separado cada sección con un comentario para que sea más fácil de ver.

Nuestra prueba puede parecer intimidante al principio, pero la mayoría de las pruebas individuales seguirán un patrón básico de arrange-act-assert pattern.

cy.contains(Some innerHTML text of DOM node)

cy.contains (text of button)
.click()

cy.contains(Updated innerHTML text of DOM node)

Dado que esta es una prueba de e a e, no encontrará ninguna burla. Nuestra aplicación se ejecutará en su versión de desarrollo completo en un navegador simulado con una interfaz de usuario. Esto será lo más cerca que podamos de probar nuestra aplicación de una manera realista.

A diferencia de las pruebas unitarias y de integración, no necesitamos afirmar explícitamente algunas cosas. Esto se debe a que algunos comandos de Cypress tienen afirmaciones predeterminadas integradas. Las aserciones predeterminadas son exactamente como suenan, se afirman de forma predeterminada, por lo que no es necesario agregar un comparador.

Aserciones predeterminadas de Cypress

Los comandos están encadenados, por lo que el orden es importante y un comando esperará hasta que se complete un comando anterior antes de ejecutarse.

Incluso al realizar pruebas con Cypress, nos apegaremos a nuestra filosofía de no probar los detalles de implementación. En la práctica, esto significará que no usaremos clases, ids o propiedades html/css como selectores si podemos evitarlo. La única vez que necesitaremos usar id es para obtener nuestro elemento de entrada de formulario.

Haremos uso del comando cy.contains() que devolverá un nodo DOM con texto coincidente. Ver e interactuar con el texto en la interfaz de usuario es lo que hará nuestro usuario final, por lo que probar de esta manera estará en línea con nuestro principio rector.

Dado que no estamos criticando ni burlándonos de nada, notará que nuestras pruebas se verán muy simples. Esto es bueno ya que se trata de una aplicación que se ejecuta en vivo, nuestras pruebas no tendrán valores artificiales.

En nuestra prueba de axios, haremos una solicitud http real a nuestro punto final. Hacer una solicitud http real en una prueba e to e es común. Luego comprobaremos si ese valor no es nulo. Luego, asegúrese de que los datos de la respuesta aparezcan en nuestra interfaz de usuario.

Si se hace correctamente, debería ver que Cypress ejecutó con éxito las pruebas en cromo.

Integración continua

Hacer un seguimiento y ejecutar todas estas pruebas manualmente puede volverse tedioso. Así que tenemos Integración Continua, una forma de ejecutar automáticamente nuestras pruebas de forma continua.

Travis CI

Para simplificar las cosas, solo usaremos Travis CI para nuestra integración continua. Sin embargo, debe saber que hay configuraciones de CI mucho más complejas que usan Docker y Jenkins.

Deberá registrarse para obtener una cuenta de Travis y Github, ambas son afortunadamente gratuitas.

Sugeriría simplemente usar la opción "Registrarse con Github" en Travis CI.

Una vez allí, puede ir al icono de su perfil y hacer clic en el botón deslizante junto al repositorio en el que desea CI.

Para que Travis CI sepa qué hacer, necesitaremos configurar un archivo .travis.yml en la raíz de nuestro proyecto.

language: node_js

node_js: 
  - stable
  
  
install:
  - npm install

script:
  - npm run test
  - npm run coveralls

Básicamente, esto le dice a Travis que estamos usando node_js, descargamos la versión estable, instalamos las dependencias y ejecutamos el comando npm run test y npm run coveralls.

Y esto es todo. Puede ir al panel de control e iniciar la compilación. Travis ejecutará las pruebas automáticamente y le dará un resultado como este. Si sus pruebas pasan, está listo para comenzar. Si fallan, su compilación fallará y deberá corregir su código y reiniciar la compilación.

Coveralls

Coverall nos brinda un informe de cobertura que esencialmente nos dice cuánto de nuestro código se está probando.

Deberás registrarte en overoles y sincronizar con tu cuenta de github. Similar a Travis CI, simplemente vaya a la pestaña Agregar repositorios y active el repositorio que también activó en Travis CI.

A continuación, ve a tu archivo package.json y agrega esta línea de código

  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --coverage",
    "eject": "react-scripts eject",
    "cypress": "node_modules/.bin/cypress open", 
    "coveralls": "cat ./coverage/lcov.info | node node_modules/.bin/coveralls"
  },

Asegúrete de agregar el indicador --coverage al comando de prueba de react-scripts test. Esto es lo que generará los datos de cobertura que usará overoles para generar un informe de cobertura.

Y puedes ver estos datos de cobertura en la consola de Travis CI después de que se hayan ejecutado las pruebas.

Dado que no estamos tratando con un repositorio privado o Travis CI pro, no tenemos que preocuparnos por los tokens de repositorio.

Una vez que hayas terminado, puedes agregar una insignia a su repositorio README copiando el enlace provisto en el tablero.

Se verá así.

Conclusion

Cuéntate entre el 20% de los mejores desarrolladores en términos de habilidad de prueba de React si completó todo el tutorial.

Gracias por leer.

Puedes seguirme en twitter para más tutoriales en el futuro: https://twitter.com/iqbal125sf?lang=en

Posicionar elementos con CSS en el desarrollo web no es tan fácil como parece. Las cosas pueden complicarse rápidamente a medida que su proyecto crece y sin tener una buena comprensión de cómo CSS se ocupa de la alineación de elementos HTML, no podrá solucionar sus problemas de alineación.

Hay diferentes maneras/métodos para posicionar elementos con CSS puro. Usando las propiedades CSS float, display y position son los métodos más comunes.

En este artículo, explicaré una de las formas más confusas de alinear elementos con CSS puro: la propiedad de position.

Vamos a empezar...

CSS Position y propiedades auxiliares

Así que hay 5 valores principales de la Propiedad Position:

position: static | relative | absolute | fixed | sticky

y propiedades adicionales para establecer las coordenadas de un elemento (Las llamo “propiedades auxiliares”):

top | right | bottom | left y la z-index

Nota importante: Las propiedades auxiliares no funcionan sin una posición declarada o con position: static.

¿Qué es este z-index?

Nosotros tenemos altura y anchura (x, y) son 2 dimensiones. Z es la 3.ª dimensión. Un elemento en la página web aparece delante de otros elementos como su z-index aumenta el valor.

Z-index no funciona con position: static o sin una posición declarada.

Ahora sigamos con los valores de las propiedades de Position...

1. Static

position: static es el valor por defecto. Ya sea que lo declaremos o no, los elementos se colocan en un orden normal en la página web. Pongamos un ejemplo:

Primero, definimos nuestra estructura HTML:

<body>
  <div class="box-orange"></div>
  <div class="box-blue"></div>
</body>

Luego, creamos 2 cajas y definimos sus width, height y position:

.box-orange {          // sin ninguna declaracion position
  background: orange;
  height: 100px;
  width: 100px;       
}

.box-blue {
  background: lightskyblue;
  height: 100px;
  width: 100px; 
  position: static;   // Declarado como estatico
}

Como podemos ver en la imagen, definir la position: static o no, no hace ninguna diferencia. Las cajas se colocan de acuerdo con el flujo normal de documento.

2. Relative

position: relative: La nueva posición de un elemento en relación con su posición normal.

Empezando con position: relative y para todos valor de position non-static, podemos cambiar la posición predeterminada de un elemento usando las propiedades auxiliares que mencioné anteriormente.

Movamos el cuadro naranja al lado del azul.

.box-orange {
  position: relative;  // Ahora estamos listos para mover el elemento
  background: orange;
  width: 100px;
  height: 100px;
  top: 100px;         // 100px para top en relacion con su position antigua
  left: 100px;        // 100px para left
}

NOTA: Usando position: relative por un elemento, no afecta las posiciones de otros elementos.

3. Absolute

En position: relative, el elemento está posicionado Relativo a sí mismo. Sin embargo, un elemento absolutamente posicionado es relativo a su padre.

Un elemento con position: absolute se elimina del flujo normal de documentos. Se posiciona automáticamente en el punto de inicio (top-left esquina) de su elemento padre. Si no tiene ningún elemento principal, Entonces el siguiente Elemento <html> Será su padre.

Dado que position: absolute elimina el elemento del flujo del documento, otros elementos se ven afectados y se comportan como si el elemento se eliminara por completo de la página web.

Agreguemos un container como elemento principal:

<body>
  <div class="container">
    <div class="box-orange"></div>
    <div class="box-blue"></div>
  </div>
</body>

.box-orange {
  position: absolute;
  background: orange;
  width: 100px;
  height: 100px;
}

Ahora parece que la caja azul ha desaparecido, pero no es así. El cuadro azul se comporta como si se quitara el cuadro naranja, por lo que sube al lugar del cuadro naranja.

Movamos el cuadro naranja 5 píxeles:

.box-orange {
  position: absolute;
  background: orange;
  width: 100px;
  height: 100px;
  left: 5px;
  top: 5px;
}

Las coordenadas de un elemento con posición absoluta son relativas a su padre si el padre también tiene una non-static position. De lo contrario, las propiedades auxiliares colocan el elemento en relación con el inicial.

.container {
  position: relative;
  background: lightgray;
}

.box-orange {
  position: absolute;
  background: orange;
  width: 100px;
  height: 100px;
  right: 5px;    // 5px relative to the most-right of parent
}

4. Fixed

Me gusta position: absolute, los elementos de posición fija también se eliminan del flujo de documentos normal. Las diferencias son:

• Solo son relativos al documento <html>, y no a ningún otro padre.
• No se ven afectados por el desplazamiento.

.container {
  position: relative;
  background: lightgray;
}

.box-orange {
  position: fixed;
  background: orange;
  width: 100px;
  height: 100px;
  right: 5px;    // 5px en relacion con el mas derecho de los padres
}

Aquí en el ejemplo, Cambio la posición del cuadro naranja a fixed, y esta vez es relativo 5px a la derecha del documento <html>, no su padre (container):

Como podemos ver, desplazarse por la página no afecta a la fixed caja posicionada. Ya no es relativa a su padre (contenedor).

5. Sticky

position: sticky puede explicarse como una mezcla de position: relative y position: fixed.

Se comporta hasta un punto declarado como position: relative, después de eso cambia su comportamiento a position: fixed. La mejor manera de explicar position: sticky es con un ejemplo:

IMPORTANTE: Position Sticky no es compatible con Internet Explorer y versiones anteriores de otros navegadores. Puede consultar el soporte del navegador en caniuse.com.

La mejor manera de entender la propiedad de posición de CSS es mediante la práctica. Continúe codificando hasta que tenga una mejor comprensión. Si algo no está claro, responderé sus preguntas a continuación en la sección de comentarios.

Si quieres saber más sobre desarrollo web, siéntete libre de ¡seguirme en Youtube!

¡Gracias por leer!

Cuando construimos proyectos, queremos mostrarlos en línea. En lugar de comprar un dominio y tomarse el tiempo para configurarlo, es más fácil hospedarlo usando GitHub Pages.

Un proyecto que solo usa JavaScript, HTML y CSS es fácil de alojar en GitHub Pages. Sin embargo, los proyectos creados en React, Vue o Angular requieren algunas configuraciones. Esto le brinda a cualquier persona que visite tu aplicación en línea la misma experiencia que tiene cuando crea la aplicación localmente.

En este artículo, te mostraré cómo crear una aplicación React simple que use enrutamiento y luego aprenderemos cómo cargarla en GitHub Pages. Daremos especial atención a la parte de enrutamiento, ya que es importante entender e implementar.

⚠️ Este artículo asume que tienes algún conocimiento de React y Git.

Requisitos previos

Debes tener Node, yarn y npm instalados en tu máquina. Para verificar si están instalados, abre una ventana de terminal y escribe lo siguiente:

npm -v
yarn -v
node -v

Si estos comandos imprimen un número de versión en la terminal, está listo para comenzar. De lo contrario, debes continuar e instalar lo que falta.

• Node (contiene npm)
• Yarn

También necesitaremos crear un repositorio en GitHub. Dirígete a tu cuenta y crea un nuevo repositorio. Elige el nombre que consideres adecuado para este proyecto, pero me quedo con starter-project para el resto de este artículo.

Para crear nuestro proyecto, usaremos create-react-app. Es un paquete que te permite crear una aplicación de una sola página con facilidad. Para crear un proyecto, debes escribir lo siguiente en la terminal:

npx create-react-app starter-project

Una vez que finalice la operación, tendrás un proyecto React repetitivo, listo para funcionar. Para ver si funciona correctamente, dirígete al directorio del proyecto (en nuestro ejemplo sería starter-project) y ejecuta el comando:

yarn start

Si todo funciona correctamente, verás un mensaje en la terminal que dice que tu aplicación se está ejecutando en un servidor local en esta dirección: http://localhost:3000

Si te diriges allí en tu navegador, verás esto:

Cómo implementar tu proyecto en GitHub

Es posible que hayas notado que no hemos creado ningún repositorio en GitHub. Entonces, antes de continuar, debemos tener nuestro proyecto cargado allí. Dirígete a tu cuenta de GitHub y crea un repositorio con el mismo nombre que el proyecto React: starter-project.

☝️ Asegúrate de marcar tu repositorio como público. Si lo marca como privado, no podrá usar las GitHub Pages.

Vamos a añadir este repositorio como remoto a nuestro proyecto. Para hacer eso, en la terminal, escriba:

git remote add <name-of-remote> <url-of-repository>

Entonces, en nuestro caso, el comando se ve así:

git remote add origin https://github.com/TomerPacific/starter-project

Es importante llamar al control remoto origin es como se utilizará en nuestro proceso de implementación.

Después de ejecutar el comando anterior, aún no podemos enviar nuestro código. Primero, necesitamos configurar una rama ascendente y establecer el control remoto como origen.

 git push --set-upstream origin master

Ahora, podemos enviar todos los archivos de nuestro proyecto a nuestro repositorio.

Para que podamos cargar nuestra aplicación creada en GitHub Pages, primero debemos instalar el paquete gh-pages.

yarn add gh-pages

Este paquete nos ayudará a implementar nuestro código en la rama gh-pages que se usará para alojar nuestra aplicación en GitHub Pages.

Para permitirnos usar el paquete gh-pages correctamente, necesitamos agregar dos claves al valor de nuestros scripts en el archivo package.json:

"scripts": {
    "start": "react-scripts start",
    "predeploy": "npm run build", <----------- #1
    "deploy": "gh-pages -d build", <---------- #2
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },

A continuación, debemos modificar nuestro archivo package.json agregando el campo de la página de inicio. React utiliza este campo para averiguar la URL raíz en el archivo HTML creado. En él pondremos la URL de nuestro repositorio de GitHub.

{
  "name": "starter-project",
  "homepage": "https://tomerpacific.github.io/starter-project/", <----
  "version": "0.1.0",
  /....
}

Para desplegar nuestra aplicación, escribe lo siguiente en la terminal:

npm run deploy

Ejecutar el comando anterior se encarga de compilar tu aplicación y enviarla a una rama llamada gh-pages, que GitHub usa para vincularse con las páginas de GitHub.

? Si no nombraste tu control remoto origin, obtendrás un error durante esta fase que indica que: Failed to get remote.origin.url (task must either be run in a git repository with a configured origin remote or must be configured with the "repo" option).

Sabrás que el proceso fue exitoso si al final del mismo ves la palabra Publicado. Ahora podemos dirigirnos a nuestro repositorio de GitHub en Configuración y desplazarnos hacia abajo hasta la sección Páginas de GitHub.

Si ves un mensaje similar al anterior, significa que tu aplicación ahora está alojada correctamente en las GitHub Pages.

Enrutamiento en React

Hasta ahora:

1. Tenemos una aplicación básica de React que está alojada en GitHub Pages
2. También tenemos un proceso simplificado para implementarlo cuando queremos hacer cambios.

Pero dado que el propósito de este artículo es mostrar una aplicación más compleja que la que creamos inicialmente, analizaremos el enrutamiento.

Un componente que falta en nuestra aplicación es la navegación. Nuestra aplicación no será solo una página, probablemente tendrá muchas páginas. Entonces, ¿cómo podrán los usuarios navegar entre ellos?

React es una biblioteca y no contiene todo lo que necesitas para su aplicación lista para usar (en nuestro caso, enrutamiento). Por lo tanto, necesitaremos instalar react router.

React router tiene diferentes componentes para aplicaciones web y para aplicaciones nativas. Como estamos construyendo una aplicación web, usaremos react-router-dom.

yarn add react-router-dom

Para hacer uso del enrutamiento en nuestra aplicación, creemos un elemento de navegación que estará visible en la parte superior de la aplicación. Agregaremos esto dentro de nuestro archivo App.js y reemplazaremos el marcado HTML actual que está allí.

 <div>
     <nav>
         <ul id="navigation">
             <li>
                 <Link to="/">Home</Link>
             </li>
             <li>
                 <Link to="/about">About</Link>
             </li>
             <li>
                 <Link to="/contact">Contact</Link>
             </li>
         </ul>
     </nav>
</div>

Por lo general, en un proyecto que no sea de React, colocaríamos una ruta relativa a nuestras páginas HTML para cada sección. De esa forma, el navegador sabe desde dónde cargar los datos.

Pero en nuestro proyecto, no tendremos diferentes páginas HTML para cada sección. Simplemente, cargaremos un componente diferente. El marcado que solía estar dentro de App.js ahora se encontrará dentro de un componente llamado Home.

import './App.css';
import React from 'react';
import logo from './logo.svg';

class Home extends React.Component {
    render() {
        return (
            <div className="App">
                <header className="App-header">
                <img src={logo} className="App-logo" alt="logo" />
                <p>
                    Edit <code>src/App.js</code> and save to reload.
                </p>
                <a
                    className="App-link"
                    href="https://reactjs.org"
                    target="_blank"
                    rel="noopener noreferrer"
                >
                    Learn React
                </a>
                </header>
            </div>
            
        );
    }

}

export default Home;

Como hemos creado tres secciones en nuestra navegación y nos hemos ocupado de la sección de inicio, vamos a dar otro ejemplo con la sección Acerca de.

Crearemos un nuevo archivo llamado About.jsx que contendrá nuestra plantilla y código para la sección acerca de.

import React from 'react';

const divStyle = {
    color:'white'
};

class About extends React.Component {
    
    render() {
        return (
            <div style={divStyle}>
                <h2>About Page</h2>
                <main>
                    <p>This section contains information about...</p>
                </main>
            </div>
        )
    }
}



export default About;

Puede que te preguntes, ¿cómo sabrá la aplicación que debe redirigir al usuario una vez que haga clic en el enlace Acerca de? Para eso usaremos un componente llamado Route.

La ruta es uno de los componentes más importantes en react-router porque te permite representar diferentes componentes según la ruta de la URL. Para nuestro proyecto, usaremos el siguiente código dentro de App.js justo debajo del marcado de navegación.

<Switch>
    <Route exact path="/">
    <Home />
    </Route>
    <Route path="/about">
    <About />
    </Route>
</Switch>

Puedes ver que creamos dos rutas para Home y About. El componente Switch nos permite agrupar los componentes de la ruta y solo coincidirá con uno de ellos.

Nuestro archivo App.js combinado se ve así:

import './App.css';
import React from 'react';
import { Route, Switch, Link } from "react-router-dom";
import About from './About';
import Home from './Home';

class App extends React.Component {
  render() {
      return (
        <div className="App">
          <div>
            <nav>
              <ul id="navigation">
                <li>
                  <Link to="/">Home</Link>
                </li>
                <li>
                <Link to="/about">About</Link>
                </li>
                <li>
                <Link to="/contact">Contact</Link>
                </li>
              </ul>
            </nav>
          </div>
            <Switch>
            <Route exact path="/">
              <Home />
            </Route>
            <Route path="/about">
              <About />
            </Route>
          </Switch>
          </div>
            );
  }
}

export default App;

Una última cosa que debemos hacer es envolver todo nuestro proyecto en un componente de enrutador. Necesitamos hacer esto porque nos permite usar el enrutamiento en nuestra aplicación. Usaremos el componente BrowserRouter, ya que usa la API de historial de HTML5.

ReactDOM.render(
  <React.StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </React.StrictMode>,
  document.getElementById('root')
);

Si ejecutamos las cosas localmente, todo parece funcionar. Implementemos nuestro proyecto en GitHub Pages y veamos cuál es el resultado.

Cómo manejar el enrutamiento usando HashRouter

A primera vista, todo parece funcionar bien. Pero cuando intente actualizar la página o navegar a través del navegador, seguirá recibiendo errores 404.

¿Por qué pasó esto? Porque las Páginas de GitHub no admiten el historial del navegador como lo hace su navegador. En nuestro caso, la ruta https://tomerpacific.github.io/starter-project/about no ayuda a las páginas de GitHub a comprender dónde apuntar al usuario (ya que es una ruta de interfaz).

Para superar este problema, necesitamos usar un Hash Router en lugar de un Browser Router en nuestra aplicación. Este tipo de enrutador usa la parte hash de la URL para mantener la interfaz de usuario sincronizada con la URL.

ReactDOM.render(
  <React.StrictMode>
    <HashRouter>
      <App />
    </HashRouter>
  </React.StrictMode>,
  document.getElementById('root')
);

Puedes leer más sobre esto aquí.

Vuelve a implementar tu aplicación y estarás satisfecho con el resultado. No más errores 404.

Escrito por Rohit Kumar

Esto es lo que construiremos en este tutorial: una buena tarjeta React como esta.

En este tutorial, utilizaremos la renderización del lado del servidor para ofrecer una respuesta HTML cuando un usuario o rastreador accede a la URL de una página. Manejaremos las últimas solicitudes en el lado del cliente.

¿Por qué lo necesitamos?

Déjame guiarte a la respuesta.

¿Cuál es la diferencia entre la representación del lado del cliente y la representación del lado del servidor?

En la renderización del lado del cliente, tu navegador descarga una página HTML mínima. Representa el JavaScript y llena el contenido en él.

Renderización del lado del servidor, por otro lado, renderiza los componentes de React en el servidor. La salida es contenido HTML.

Puede combinar estos dos para crear una aplicación isomorfa.

Contras de renderizar React en el servidor

• SSR puede mejorar el rendimiento si su aplicación es pequeña. Pero también puede degradar el rendimiento si es pesado.
• Aumenta el tiempo de respuesta (y puede ser peor si el servidor está ocupado).
• Aumenta el tamaño de la respuesta, lo que significa que la página tarda más en cargarse.
• Aumenta la complejidad de la aplicación.

¿Cuándo debería utilizar la representación del lado del servidor?

A pesar de estas consecuencias de SSR, hay algunas situaciones en las que puede y debe usarlo.

1. SEO

Todos los sitios web quieren aparecer en las búsquedas. Corrígeme si me equivoco.

Desafortunadamente, los rastreadores de los motores de búsqueda aún no entienden o procesan JavaScript.

Esto significa que ven una página en blanco, sin importar cuán útil sea su sitio.

Mucha gente dice que el rastreador de Google ahora muestra JavaScript.

Para probar esto, implementé la aplicación en Heroku. Esto es lo que vi en la consola de búsqueda de Google:

Una página en blanco.

Esta fue la principal razón por la que exploré el renderizado del lado del servidor. Especialmente cuando se trata de una página fundamental, como una página de destino, un blog, etc.

Para verificar si Google renderiza tu sitio, visite:

Panel de la Consola de Búsqueda > Inspeccionar URL > Explorar como Google. Ingrese la URL de la página o déjela vacía para la página de inicio.

Selecciona BUSCAR Y RENDERIZAR. Una vez completado, haga clic para ver el resultado.

2. Mejorar el rendimiento

En SSR, el rendimiento de la aplicación depende de los recursos del servidor y la velocidad de la red del usuario. Esto lo hace muy útil para sitios con mucho contenido.

Por ejemplo, supongamos que tienes un teléfono móvil de precio medio con una velocidad de internet lenta. Intenta acceder a un sitio que descarga 4 MB de datos antes de poder ver nada.

¿Serías capaz de ver algo en tu pantalla dentro de 2 a 4 segundos?

¿Volverías a visitar ese sitio?

No creo que lo harías.

Otra mejora importante es el tiempo de interacción con el primer usuario. Esta es la diferencia en el tiempo desde que un usuario accede a la URL hasta que ve el contenido.

Aquí está la comparación. Lo probé en una Mac de desarrollo.

React renderizado en el servidor

El tiempo de la primera interacción es de 300ms. Hidratar los acabados a los 400ms. El evento de carga sale a los 500ms aproximadamente. Puedes ver esto mirando la imagen de arriba.

React renderizado en el navegador del cliente

El tiempo de la primera interacción es de 400ms. El evento de carga sale a los 470 ms.

El resultado habla por sí mismo. Hay una diferencia de 100 ms en el tiempo de interacción del primer usuario para una aplicación tan pequeña.

¿Cómo funciona? — (4 pasos simples)

• Cree una tienda Redux nueva en cada solicitud.
• Opcionalmente, envíe algunas acciones.
• Saque el estado de la tienda y almacena realiza SSR.
• Envía el estado obtenido en el paso anterior junto con la respuesta.

Usaremos el estado pasado en la respuesta para crear el estado inicial en el lado del cliente.

Antes de comenzar, clone o descargue el ejemplo completo de Github y utilícelo como referencia.

Primeros pasos configurando nuestra aplicación

Primero, abra su editor y Shell favoritos. Cree una nueva carpeta para su aplicación. Empecemos.

npm init --yes

Complete los detalles. Después es generado package.json, copie las dependencias y scripts a continuación en él.

Instale todas las dependencias ejecutando:

npm install

Ahora debe configurar Babel y webpack para que nuestro script de compilación funcione.

Babel transforma ESM y React en código que el navegador pueda entender.

Crear un nuevo archivo .babelrc y poner la línea de abajo en él.

{
  "presets": ["@babel/env", "@babel/react"]
}

webpack agrupa nuestra aplicación y sus dependencias en un solo archivo. Crear otro archivo webpack.config.js con el siguiente código en él:

const path = require('path');module.exports = {
    entry: {
        client: './src/client.js',
        bundle: './src/bundle.js'
    },
    output: {
        path: path.resolve(__dirname, 'assets'),
        filename: "[name].js"
    },
    module: {
        rules: [
            { test: /\.js$/, exclude: /node_modules/, loader: "babel-loader" }
        ]
    }
}

Los dos archivos de salida del proceso de compilación:

1. assets/bundle.js — aplicación pura del lado del cliente.
2. assets/client.js — Aplicación del lado del servidor SSR.

La src/ carpeta contiene el código fuente. Los archivos compilados de Babel van en views/. views el directorio se creará automáticamente si no está presente.

¿Por qué necesitamos compilar archivos fuente?

Desafortunadamente, React no funcionan en Node. Aquí viene Babel al rescate. El siguiente script le dice a Babel que compile todos los archivos en la carpeta src y ponga el resultado en la carpeta views.

"babel": "babel src -d views",

Ahora, Node puede ejecutarlos.

Copia archivos precodificados y estáticos

Si ya ha clonado el repositorio, cópielo. De lo contrario, descargue el archivo ssr-static.zip de Dropbox. Extráigalo y mantenga estas tres carpetas dentro del directorio de su aplicación. Esto es lo que contienen.

1. React App y los componentes residen en src/components.
2. Archivos redux en src/redux/.
3. assets/ & media/: Contiene archivos estáticos como style.css y las imágenes.

Lado del servidor

Crear dos nuevos archivos llamados server.js y template.js dentro de src/ carpeta.

1. src/server.js

La magia sucede aquí. Este es el código que has estado buscando.

import React from 'react';
import { renderToString } from 'react-dom/server';
import { Provider } from 'react-redux';
import configureStore from './redux/configureStore';
import App from './components/app';

module.exports = function render(initialState) {
  // Model the initial state  
  const store = configureStore(initialState);
  let content = renderToString(<Provider store={store} ><App /></Provider>);
  const preloadedState = store.getState();
  return {
    content,
    preloadedState
  };
};

En lugar de representar nuestra aplicación, debemos envolverla en una función y exportarla. La función acepta el estado inicial de la aplicación.

Así es como funciona.

1. Pasa initialState a la función configureStore(). configureStore()devuelve una nueva instancia de Store. Lo almacena dentro de la variable store.
2. Llama el método renderToString(), proporciona nuestra aplicación como entrada. Representa nuestra aplicación en el servidor y devuelve el HTML producido. Ahora, la variable content almacena el HTML.
3. Saca el estado de Redux Store llamando getState() en store. Guárdalo en una variable preloadedState.
4. Devuelve content y preloadedState. Los pasaremos a nuestra plantilla para obtener la página HTML final.

2. src/template.js

template.js exporta una función. Se necesita title, state y content como entrada. Los inyecta en la plantilla y devuelve el documento HTML final.

Para pasar a lo largo del estado, la plantilla adjunta state a window.__STATE__ dentro de una <script>i etiqueta.

Ahora puedes leer state en el lado del cliente accediendo window.__STATE__.

También incluimos el compañero SSR assets/client.js aplicación del lado del cliente en otra etiqueta de secuencia de comandos.

Si solicita la versión de cliente puro, solo pone assets/bundle.js dentro de la etiqueta del script.

El lado del cliente

El lado del cliente es bastante sencillo.

1. src/bundle.js

Así es como se escribe React y Redux Provider envuelto. Es nuestra aplicación pura del lado del cliente. No hay trucos aquí.

import React from 'react';
import { render } from 'react-dom';
import { Provider } from 'react-redux';
import configureStore from './redux/configureStore';
import App from './components/app';

const store = configureStore();
render(
  <Provider store={store} > <App /> </Provider>,
  document.querySelector('#app')
);

2. src/client.js

¿Luce familiar? Sí, no hay nada especial, excepto window.__STATE__. Todo lo que tenemos que hacer es tomar el estado inicial de window.__STATE__ Y pasarlo a nuestra función configureStore() como el estado inicial.

Echemos un vistazo a nuestro nuevo archivo de cliente:

import React from 'react';
import { hydrate } from 'react-dom';
import { Provider } from 'react-redux';
import configureStore from './redux/configureStore';
import App from './components/app';

const state = window.__STATE__;
delete window.__STATE__;
const store = configureStore(state);
hydrate(
  <Provider store={store} > <App /> </Provider>,
  document.querySelector('#app')
);

Repasemos los cambios:

1. Reemplaza render() con hydrate(). hydrate() es lo mismo que render(), pero se utiliza para hidratar elementos producidos por ReactDOMServer. Garantiza que el contenido sea el mismo en el servidor y en el cliente.
2. Lee el estado del objeto en window object window.__STATE__. Guárdelo en una variable y elimine el window.__STATE__.
3. Crea una nueva tienda con state como estado inicial.

Todo hecho aquí.

Poniéndolo todo junto

Index.js

Este es el punto de entrada de nuestra aplicación. Maneja solicitudes y plantillas.

También declara una variableinitialState. Lo he modelado con datos en el archivo assets/data.json . La pasaremos a nuestra función ssr().

Nota: Al hacer referencia a un archivo que está dentro src/ de un archivo fuera src/, uso normal require() y reemplace src/ por views/. tu sabes la razon (compila Babel).

Enrutamiento

1. /: Por defecto, la página de inicio renderizada por el servidor.
2. /client: Ejemplo puro de representación del lado del cliente.
3. /exit: Botón de parada del servidor. Solo disponible en desarrollo.

Construir y ejecuta

Es hora de construir y ejecutar nuestra aplicación. Podemos hacer esto con una sola línea de código.

npm run build && npm run start

Ahora, la aplicación se está ejecutando en http://localhost:3000.

¿Listo para convertirte en un Pro en React?

Comenzaré una nueva serie a partir del próximo lunes para que tus habilidades de React ardan de inmediato.

Gracias por leer este tutorial

En la programación diaria, a menudo necesitamos trabajar con cadenas. Afortunadamente, hay muchos métodos incorporados en JavaScript que nos ayudan mientras trabajaban con matrices, cadenas y otros tipos de datos. Podemos usar estos métodos para varias operaciones como buscar, reemplazar, concatenar cadenas, etc.

Obtener una subcadena de una cadena es una de las operaciones más comunes en JavaScript. En este artículo, aprenderá cómo obtener una subcadena mediante el uso de 3 métodos integrados diferentes. Pero primero, déjame explicarte qué es probable que sea una subcadena.

¿Qué es una subcadena?

Una subcadena es un subconjunto de otra cadena:

"I am learning JavaScript and it is cool!"  -->  Original String

"I am learning JavaScript"  -->  Substring

"JavaScript is cool!"  -->  Another Substring

Como en el ejemplo anterior, en algunos casos necesitamos obtener una o más subcadenas de una oración completa o un párrafo. Ahora veamos cómo hacer eso en JavaScript de 3 maneras diferentes.

1. El método de la subcadena()

Empecemos con el método substring(). Este método básicamente obtiene una parte de la cadena original y la devuelve como una nueva cadena. El método de subcadena espera dos parámetros:

string.substring(startIndex, endIndex);

• startIndex : representa el punto de inicio de la subcadena
• endIndex : representa el punto final de la subcadena (opcional)

Veamos el uso en un ejemplo. Supongamos que tenemos la siguiente cadena de ejemplo:

const myString = "I am learning JavaScript and it is cool!";

Ahora, si configuramos startIndex como 0 y endIndex como 10, obtendremos los primeros 10 caracteres de la cadena original:

Sin embargo, si establecemos solo un índice inicial y ningún índice final para este ejemplo:

Luego obtenemos una subcadena que comienza desde el sexto carácter hasta el final de la cadena original.

Algunos puntos adicionales:

• Si startIndex = endIndex, el método de subcadena devuelve una cadena vacía
• Si startIndex y endIndex son mayores que la longitud de la cadena, devuelve una cadena vacía
• Si startIndex > endIndex, el método de subcadena intercambia los argumentos y devuelve una subcadena, asumiendo que endIndex > startIndex

2. El método slice( )

El método slice( ) es similar al método substring( ) y también devuelve una subcadena de la cadena original. El método slice() también espera los mismos dos parámetros:

string.slice(startIndex, endIndex);

• startIndex: representa el punto de partida de la subcadena
• endIndex: representa el punto final de la subcadena (opcional)

Los puntos comunes de los métodos substring() y slice():

• Si configuramos startIndex y endIndex, obtendremos los caracteres entre los números de índice dados de la cadena original:

• Si startIndex y endIndex son mayores que la longitud de la cadena, devuelve una cadena vacía

Diferencias del método slice():

• Si startIndex es un número negativo, entonces el primer carácter comienza desde el final de la cadena (al revés):

Nota: Podemos usar el método slice() también para arreglos de JavaScript.

3. El método substr()

Según los documentos de Mozilla , el método substr() se considera una función heredada y se debe evitar su uso. Pero aún explicaré brevemente lo que hace porque es posible que lo vea en proyectos más antiguos.

El método substr( ) también devuelve una subcadena de la cadena original y espera dos parámetros como:

string.substring(startIndex, length);

• startIndex : representa el punto de inicio de la subcadena
• length: número de caracteres a incluir (opcional)

Puede ver la diferencia aquí: el método substr() espera que el segundo parámetro sea una longitud en lugar de un índice final:

En este ejemplo, básicamente cuenta 5 caracteres que comienzan con el índice de inicio dado y los devuelve como una subcadena.

Sin embargo, si no definimos el segundo parámetro, regresa hasta el final de la cadena original (como lo hacen los dos métodos anteriores):

Nota: Los 3 métodos devuelven la subcadena como una nueva cadena y no cambian la cadena original.

Conclusión

Estos son los 3 métodos diferentes para obtener una subcadena en JavaScript. Hay muchos otros métodos incorporados en JS que realmente nos ayudan mucho cuando tratamos con varias cosas en la programación. Si encuentra útil esta publicación, compártala en las redes sociales.

Si quieres aprender más sobre desarrollo web, ¡no dudes en seguirme en Youtube !

¡Gracias por leer!