React

La mayoría de demos con agentes funcionan muy bien hasta que aparece el primer problema real: hay que persistir contexto, exponer capacidades por HTTP, desacoplar eventos, aguantar reinicios y, además, mantener el sistema operable por un equipo backend normal.

Ahí es donde Dapr Agents resulta interesante. No tanto por la palabra “agent”, sino porque aterriza el problema sobre piezas de plataforma que ya conocemos: state stores, pub/sub, workflows, APIs y sidecars.

En este artículo voy a contar cómo encaja esa idea en un proyecto real: D&D Copilot, un juego conversacional con backend en ASP.NET Core, frontend en React y una capa de NPCs que ya adopta varios conceptos de Dapr Agents aunque la aplicación esté implementada en .NET.

Aunque hay muchas formas de escribir estilos cuando trabajamos con React.js, es bastante habitual usar Sass, que no es más que CSS con superpoderes, para escribir las hojas de estilos pero que requieren de una pequeña librería para compilar lo que hemos escrito en reglas CSS puras. Es aquí donde entraba el archiconocido node-sass que tantos quebraderos de cabeza solía dar, pero…

Aunque el concepto de React.JS y Web Components es muy parecido en el fondo, crear componentes reutilizables, resuelven problemas diferentes porque se aplican a contextos muy distinto ya que, Web Components se basa en crear mini-componentes que puedan ser incrustados en cualquier desarrollo web y en React.JS se crean componentes que pueden ser reutilizados dentro de cualquier desarrollo con React. Pero ¿es posible mezclar ambos mundos? La respuesta es sí, y además de una forma muy sencilla.

En ocasiones, al desarrollar aplicaciones web es necesario realizar un diseño que acepte el cambio de Tema para adaptarlo a las necesidades del cliente de forma dinámica y que pueda personalizar su experiencia. Si estamos usando React.JS junto con JSS para aplicar los estilos, podemos hacerlo de forma manual añadiendo el código necesario o, usar la característica de Theming de JSS.

Al desarrollar un proyecto siempre es necesario disponer de diferentes entornos para poder desarrollar y testear antes de pasar a producción. Así, es habitual tener entornos de Desarrollo, Pre-Producción y Producción aunque también podemos encontrarnos con escenarios con más (o menos) entornos. Por ello, es necesario disponer de variables de entorno que puedan ser configurables de forma automática a la hora de compilar/ejecutar nuestras aplicaciones react, tales como URLs de Apis, Client Ids, etc.

Cuando creamos un proyecto de React.JS con la plantilla, por defecto se ejecutará en el puerto 3000, lo que hará que pueda darnos conflicto con otros proyectos que tengamos en ejecución si, como en mi caso, hacéis pruebas en proyectos paralelos mientras desarrolláis la aplicación principal. Entonces, ¿cómo lo cambiamos?

Este es el primero de una serie de artículos en los que voy a ir detallando, a modo de tutorial cómo construir aplicaciones web con React.JS usado en conjunto con ASP.Net Core 2.0. En primer lugar, hemos de empeza con una breve introducción a React.JS para entrar en contexto y poder avanzar en sus características y así poder exprimir todo el jugo que nos puede dar.