Angular.js ha sido el marco MVC elegido por los principales desarrolladores durante años, pero gracias a los ingenieros de Facebook, esto cambiará en 2015. React está reclamando una gran porción del mercado, con grandes jugadores ya a bordo incluyendo Netflix, Yahoo y airbnb, por nombrar algunos. React es a menudo catalogada como la V en MVC, y es discutiblemente la V más rápida hasta ahora; los principales marcos (Angular incluido) ya han aprendido de ella. Los ingenieros de Facebook están desafiando tanto los estándares de MVC como los de REST, y proponiendo cambios radicales en la forma en que escribimos las aplicaciones web. Esto es lo que debes saber.
¿Qué hay dentro de qué?
En lugar de escribir JavaScript dentro del HTML (por ejemplo, rodeando un
Todos sabemos que el Modelo de Objeto de Documento (DOM) es el cuello de botella más lento en el desarrollo de la Web. Y React ofrece una solución, usando el DOM Virtual; ya que el DOM es lento en el navegador, React representa el DOM en el propio JavaScript. Ahora, cuando ese conjunto de operaciones está hecho, tenemos en JavaScript un «diff» del DOM Virtual que teníamos antes, y el DOM que deberíamos tener después. React aplica esa «diff» al DOM, y continúa con el siguiente conjunto de cambios cuando éstos ocurren. Esto demostró ser una forma más rápida que cualquier otra cosa en el mismo dominio.
Por supuesto, escribir HTML en JavaScript no es fácil, así que ¿cómo podemos seguir escribiendo HTML mientras seguimos cosechando los beneficios del DOM Virtual? La respuesta de Facebook es JSX. HTML es todo sobre estructuras de árboles y atributos, y JSX permite tomar esas estructuras y convertirlas automáticamente a llamadas de la función Reaccionar de JavaScript. Con JSX, se escriben las vistas de la manera familiar y concisa que se conoce (muy similar al HTML, con diferencias menores), y luego se transforma todo JSX en React nativo antes de servirlo al cliente (un proceso que puede ser fácilmente automatizado). JSX no es necesario para escribir aplicaciones de React, pero es mucho más fácil de escribir, leer y mantener.
¿Bueno o malo?
En lugar de la arquitectura y los conceptos de Modelo-Vistas-Controladores (MVC), como la unión de datos entre las vistas y los modelos, el sistema frontal debería tener un flujo de datos unidireccional. Sus vistas nunca deben cambiar los modelos directamente, aunque siempre se leen de los modelos. Y para escribir, desencadenan acciones que eventualmente se envían a los modelos (los modelos se denominan «almacenes» en este flujo). React encaja perfectamente en este flujo por la forma en que reacciona a los cambios de datos en los almacenes (ya que siempre los está escuchando), y vuelve a representar las vistas de forma eficiente (gracias al Virtual DOM).
Entonces, ¿qué es exactamente lo que está mal con el MVC? A pequeña escala funciona bien, pero cuando tu aplicación crece en múltiples modelos y múltiples vistas, las relaciones entre ellos se complican. Cualquier vista puede leer y escribir en cualquier modelo… y con el autoencuadernado, los modelos pueden escribir en otras vistas, que a su vez harán su propia escritura. Este flujo de ida y vuelta podría causar una actualización en cascada, y aunque puede evitarse con un buen código, la idea de que las cosas vayan en múltiples direcciones da miedo. La solución está en las restricciones verificables; tener un flujo forzado en una sola dirección es la alternativa inteligente. En cualquier parte de la aplicación, sabes que sólo hay una dirección a la que ir. El patrón de flujo es un intento de explorar esta idea, y funciona como un encanto.
GraphQL
En lugar de las API de REST, haga que el cliente pida exactamente lo que quiere (usando un gráfico), y que el servidor analice ese gráfico (con un solo punto final), y responda con exactamente lo que el cliente pidió (sin sobrecargar, sin infracargar). GraphQL es un gran ajuste para ese gráfico con el que el cliente puede preguntar al servidor.
Asumamos que la respuesta será eventualmente JSON (no tiene por qué serlo, pero aún no estamos rascando ese estándar); un JSON será un conjunto de claves y valores (más o menos, con conjuntos anidados y una matriz de conjuntos). Sabemos que los valores vendrán del servidor. Las claves, por otro lado, son exactamente lo que la vista está usando (como en renderizar el nombre de la persona aquí, y la dirección de la persona allí). Por lo tanto, si quitamos la respuesta JSON de todos los valores, de forma recursiva, lo que nos queda es esa extraña clave sólo, sin datos JSON; simplemente una cadena GraphQL. GraphQL es mucho más que eso, pero no podemos hacerle justicia aquí, así que busque una entrada de blog sobre ello pronto.
RelevoJS
En lugar de la separación estándar recomendada de datos y vistas, y dado que sólo la vista sabe exactamente qué elementos de datos son necesarios para su correcta representación, no separe estos dos en absoluto. En lugar de ello, ubíquelos conjuntamente y haga que los datos necesarios se expresen directamente en el propio componente de la vista. Esto permitirá a una vista que renderice 10 nombres y direcciones, junto con números de teléfono, correos electrónicos y enlaces sociales, para pedir al servidor TODOS los datos en un solo viaje, y obtener exactamente lo que necesita.
GraphQL puede ser usado para expresar los requerimientos de datos, y un servidor GraphQL pondrá valores en esas claves GraphQL. Pero la belleza no termina ahí… ¿qué pasa si una acción desencadena una necesidad de datos para múltiples vistas? Ya que tenemos un punto final con el que hablar, podríamos fusionar nuestros gráficos. Pero luego está la complejidad de esa fusión, tratando con los datos cuando regresan, y haciéndolos disponibles para los componentes de React, a través de las propiedades, entre otras cosas.
Aquí es donde entra el Relevo JS. Básicamente, es un marco para manejar estas operaciones, y otros mecanismos de datos como la paginación, el filtrado y la clasificación. Con Relay, declaras los datos requeridos por cada componente con GraphQL, y Relay averigua cuándo y cómo obtenerlos. Relay también agrega todas las consultas necesarias en solicitudes de red eficientes y da a los componentes exactamente lo que necesitan, cuando lo necesitan. También gestiona las operaciones de escritura con las mutaciones de GraphQL, y ofrece consistencia, actualizaciones optimizadas y manejo de errores. El relé se construye sobre el patrón de flujo y reduce el patrón a un solo almacén, manejando el crudo que antes se necesitaba para preparar y despachar acciones manualmente.
Aprende una vez, escribe en cualquier lugar
React Native te permite aplicar los mismos conocimientos que aprendiste con React, pero en lugar de apuntar a los componentes web, apuntas a los componentes de visualización que se traducen de forma nativa a las aplicaciones iOS y Android. En resumen, obtienes lo mejor de ambos mundos.
Cuando se usan juntos, React, GraphQL y Relay forman una pila increíblemente fuerte, que me gusta llamar RGR. La pila RGR podría volar REST para siempre, y empujar el patrón MVC al borde de la extinción. En unos pocos años, escribir aplicaciones MVC en los puntos finales de REST podría ser cosa del pasado. El marco de trabajo de React Native tiene el potencial de dominar el desarrollo de aplicaciones nativas y aprovechar los puntos finales compartidos con las aplicaciones web correspondientes. ¿En resumidas cuentas? Escribir aplicaciones nativas es difícil, React Native está en una posición única para cambiar eso para siempre.