Video Summary and Transcription
La charla de hoy discutió el desarrollo de Argo, un marco para el renderizado remoto de contenido dentro de las aplicaciones de Shopify. Los conceptos principales incluyen la creación de un sandbox de JavaScript, la implementación de una capa de llamada a procedimiento remoto y el uso de proxies. La charla exploró el flujo de renderizado de contenido de principio a fin, la construcción del script del worker, el renderizado de componentes de interfaz de usuario y las ventajas del renderizado remoto en cuanto a seguridad y flexibilidad. La charla también abordó los desafíos enfrentados y la naturaleza de código abierto del proyecto.
1. Introducción a la Representación Remota con Web Workers
Hoy, les guiaré a través de cómo construimos Argo, un marco extensible que permite la representación de contenido remoto dentro de las aplicaciones de Shopify. Los conceptos clave detrás de la representación remota incluyen la creación de un sandbox de JavaScript, la implementación de una capa de llamada a procedimientos remotos y el uso de proxies. Nuestro objetivo era habilitar la representación remota, proporcionar una buena experiencia de usuario, una buena experiencia de desarrollo y una capa de seguridad.
Hola a todos. Mi nombre es Trish Thao. Gracias por acompañarme en esta charla sobre la representación remota con web workers. Hoy, les guiaré a través de cómo construimos Argo, un marco extensible que permite la representación de contenido remoto dentro de las aplicaciones de Shopify. Esto es lo que cubriremos hoy. Hablaré sobre los conceptos clave. Cómo construimos Argo, el flujo de extremo a extremo. Cómo podemos reemplazar React. Y luego haré una demostración rápida de todas las piezas trabajando juntas. Estos son los conceptos clave detrás de la representación remota. Primero, necesitamos crear un sandbox de JavaScript. Este sandbox nos permite ejecutar código de manera segura en un hilo de fondo. La comunicación con el hilo principal se puede lograr mediante el envío de mensajes. Esto se implementa como un web worker en la web. En iOS y Android, esto se implementa como un motor de JavaScript sin cabeza. Luego, necesitamos implementar una capa de llamada a procedimientos remotos, RPC por sus siglas en inglés. Este es un protocolo que permite que un programa llame al servicio en otro programa. Por último, hacemos uso de proxies. Un proxy es un envoltorio que intercepta y redefine las operaciones principales del objetivo, como invocar funciones o acceder a propiedades. Hablaré sobre cómo construimos Argo. En primer lugar, lo que intentábamos lograr es habilitar la representación remota. Lo que esto significa es permitir que un script externo defina la interfaz de usuario y luego permitir que la aplicación principal la represente de forma nativa. El marco permite que el script externo intercambie datos con la aplicación principal. Esto resulta en la representación de la interfaz de usuario y la ejecución de comportamientos personalizados. Entonces, los objetivos que intentábamos lograr son proporcionar una buena experiencia de usuario. El contenido de la interfaz de usuario inyectado es indistinguible del contenido nativo propio de Shopify en todas las plataformas. Queríamos proporcionar una buena experiencia de desarrollo. Los scripts externos se pueden construir utilizando lenguajes familiares como JavaScript y TypeScript, y marcos como React o Vue, y también queríamos proporcionar una capa de seguridad. El script externo solo puede acceder y ejecutar las API proporcionadas por Shopify. En resumen, esto es lo que intentábamos hacer. Tenemos un JavaScript
2. Flujo de extremo a extremo de la representación de contenido
A través de un proxy RPC, el script puede llamar a RenderUI dentro de la aplicación principal. Argo se construyó sobre una biblioteca llamada RemoteUI, que proporciona una capa de comunicación, un árbol de componentes remotos y una capa de proxy. El flujo de extremo a extremo implica configurar el worker, cargar el script externo, construir la interfaz de usuario y representarla. La configuración incluye la creación de un worker, la configuración de la capa RPC y el establecimiento de un canal de comunicación. El receptor gestiona el árbol de componentes y el controlador especifica la implementación de la interfaz de usuario. Por último, el renderizador remoto convierte el árbol de componentes en una interfaz de usuario.
sandbox que carga un script externo dentro de él. A través de un proxy RPC, el script puede llamar a RenderUI dentro de la aplicación principal. Cuando un usuario interactúa con la interfaz de usuario, por ejemplo, al hacer clic en un botón, si el controlador está definido dentro del script externo, la aplicación principal puede llamar al controlador a través de la capa RPC. Argo se construyó sobre una biblioteca llamada RemoteUI. Esta biblioteca proporciona lo siguiente. Una capa de comunicación entre el sandbox de JavaScript y la aplicación principal. Un árbol de componentes remotos en el que el script externo puede operar y el host puede representar. Una capa de proxy que permite al host llamar a funciones definidas en el sandbox de JavaScript y viceversa. Ahora les hablaré sobre el flujo de extremo a extremo de cómo se representa el contenido. En la web, primero el host realiza algunos pasos de configuración para configurar el worker. Luego cargamos el script externo. Y luego el script externo construye la interfaz de usuario utilizando nuestras bibliotecas. Luego llama a la representación. Esto resulta en que el host reciba un mensaje con el árbol de componentes serializado, que finalmente se representa como una interfaz de usuario. Profundizando en toda la configuración, estamos construyendo un componente de extensión que puede comunicarse con un web worker. Comenzamos configurando el worker y la capa RPC. Creamos un worker con un archivo worker.js. Más adelante profundizaré en qué es esto. Y luego llamamos a create endpoint para crear un canal de comunicación entre el host y un worker. Esta función create endpoint es proporcionada por Remote UI. Y luego devolvemos la extensión. El método de llamada de endpoint. Este es un proxy que permite que las funciones dentro del worker se ejecuten de forma asíncrona por el host a través del paso de mensajes.
A continuación, configuramos una instancia del receptor remoto. Este receptor gestiona un árbol de componentes internos en respuesta a los mensajes. También configuramos un controlador que especifica la implementación a utilizar al representar la interfaz de usuario. En este ejemplo, permitimos que los botones se representen utilizando el componente de botón de la biblioteca de interfaz de usuario Polaris. El host puede decidir qué componentes se utilizarán. Esto permite cambiar los componentes según sea necesario. El último paso es representar el componente renderizador remoto de la biblioteca de interfaz de usuario remota y pasarle el receptor y el controlador. El renderizador remoto es responsable de convertir el árbol de componentes que recibe en una interfaz de usuario utilizando la implementación especificada por nuestro controlador.
3. Dentro del script del worker
Dentro del script del worker, definimos una función de representación que puede ser llamada por el host. Configuramos la capa RPC para el intercambio de datos y llamadas de proxy entre el worker y el host. También exponemos variables globales y restringimos ciertas funciones. El host puede llamar a la función de representación con el script externo y el punto de extensión. El script externo puede ejecutar un comportamiento personalizado, como representar una interfaz de usuario personalizada utilizando JSX.
Ahora veamos qué hay dentro del script del worker. Dentro del worker, definimos una función de representación que el host podrá llamar con una URL de script, un punto de extensión y un controlador de mensajes. El primer paso es llamar a import scripts con la URL del script externo para cargarlo. Luego creamos una ruta remota y pasamos nuestro controlador de mensajes. Esto establece la conexión entre el receptor del host y la raíz remota del worker. También creamos un mapa de devoluciones de llamada de extensión registradas. Dependemos del script externo para poblar el mapa. Cuando se llama a la función de representación, obtenemos la devolución de llamada registrada para el punto de extensión y la llamamos con la raíz remota. Aquí también podemos pasar datos adicionales o APIs para que el script externo pueda acceder a ellos. Pero este ejemplo solo muestra que pasamos la raíz remota. A continuación, configuramos la capa RPC del worker creando un punto de conexión al worker. Esto es el contraparte del punto de conexión creado en el host. Luego llamamos a exponer la función de representación. Internamente, la capa RPC gestiona automáticamente el almacenamiento de la función en memoria y luego responde a un mensaje del host para activar la función de representación cuando sea necesario. Esto permite de manera transparente que el worker y el host intercambien datos y realicen llamadas de proxy entre sí. Otra cosa que se encuentra dentro del archivo del worker es configurar variables globales disponibles para el script externo. Aquí es donde exponemos la función extend bajo el espacio de nombres Shopify. El script externo podrá llamar a esta función para registrar una devolución de llamada que se guardará en el mapa que vimos anteriormente. Y también podemos restringir las variables globales disponibles para el script externo. Estamos eliminando la capacidad de llamar a import scripts para que no se puedan cargar scripts adicionales. Finalmente, una vez que la función de representación está configurada dentro del worker, el host solo necesita llamar a render con el script externo y el punto de extensión. El punto de extensión se configura a través de un playground de cadena. Esto es solo una representación de un punto disponible en el host en el que los scripts externos pueden ejecutar un comportamiento personalizado. También estamos pasando el método receiver.receive que servirá como controlador para los mensajes que llegan desde la ruta remota. Vamos a ver el script externo dentro del worker. Una vez cargado, se puede ejecutar un comportamiento personalizado. Aquí hay un ejemplo de un script externo JSX que representa una interfaz de usuario personalizada. Primero, el script importa un componente de botón de nuestra biblioteca React. Luego, el script crea un componente de aplicación que representa el botón con un título y una devolución de llamada asignada a través de la propiedad onpress. La escritura del script es exactamente
4. Explorando el Componente de Botón y Renderizado
El componente de botón en la biblioteca Argo React se construye utilizando el componente remoto de React proporcionado por Remote UI. La función onpress se convierte en una promesa debido a la ejecución asíncrona. La biblioteca Argo proporciona las funciones extend y render para llamar y renderizar la interfaz de usuario. El método extend llama a Shopify extend, mientras que el método render configura un reconciliador personalizado de React. El reconciliador administra el árbol de componentes y se comunica con el host para el renderizado de la interfaz de usuario. El mensaje de montaje en el lado del host contiene los hijos desde la raíz remota, representados como nodos con IDs y props únicos. La función onPress se convierte en una función proxy para el manejo de RPC.
Es lo mismo que escribir cualquier otra aplicación React. Ahora veamos el componente de botón de la biblioteca Argo React. Se construye llamando al componente remoto de React proporcionado por Remote UI. Esta función sigue la misma interfaz que un componente funcional de React. Una cosa a tener en cuenta es que onpress ahora se convierte en una función que devuelve una promesa. Esto se debe a que todas las funciones pasadas a través de la capa RPC siempre devuelven una promesa, ya que se ejecutan de forma asíncrona mediante el envío de mensajes. Si estás utilizando un editor con TypeScript habilitado, tendrás acceso a la escritura estática y el autocompletado de código, al igual que cualquier otro componente de React. Una vez que el script configura el componente de la aplicación, necesita llamar a render para renderizar realmente la interfaz de usuario. La biblioteca Argo proporciona dos funciones, extend y render. Extend proporciona una forma de llamar a una devolución de llamada para un punto de extensión específico. En este ejemplo, estamos configurando la devolución de llamada para el punto de extensión del playground, que es el mismo habilitado por el host. Luego configuramos la devolución de llamada para llamar a render y devolver nuestro componente de la aplicación que definimos anteriormente.
Si profundizamos en el método extend proporcionado por la biblioteca, simplemente llama a Shopify extend, el método que hemos definido anteriormente en el script del worker. La biblioteca se encarga de los detalles de implementación al proporcionar la función extend. De manera similar, la biblioteca Argo también proporciona el método render que se encarga de los detalles de implementación. A alto nivel, esta función recibe una devolución de llamada de renderizado y devuelve una función que puede ser activada con una raíz remota. Luego configura un reconciliador personalizado de React. Para simplificar las cosas, he omitido nuestros convicts personalizados que se pasan al reconciliador, pero puedes pensar en este reconciliador como un reconciliador similar a React DOM o React Native. Sin embargo, está conectado a nuestra raíz remota, lo que permite que la raíz remota administre el árbol de componentes interno y se comunique con el host para realizar el renderizado de la interfaz de usuario.
Una vez que se configura el reconciliador, llamamos a la devolución de llamada de renderizado del script externo. Y luego agregamos los resultados al contenedor de la raíz remota. Y finalmente, llamamos a mount en la raíz remota. En el lado del host, recibimos un mensaje de montaje y los hijos desde la raíz remota como carga útil. Al profundizar en la carga útil de renderizado, obtenemos una matriz de objetos que representan cada nodo en el árbol. Recuerda que configuramos las props de la siguiente manera en el script externo. Tenemos un botón con un título y onPressedCallback. Esto se convierte en un nodo que tiene un ID único, el tipo que representa su implementación y las props especificadas. Puedes ver que onPress ahora se convierte en una función proxy. Cuando se llama al proxy, la capa RPC se encarga de llamar al controlador correcto con el ID de proxy coincidente desde dentro del worker, y luego se activa la devolución de llamada SayHi. También recibimos los hijos como una matriz de objetos. En este caso, no tenemos hijos, por lo que la matriz está vacía.
5. Renderizado de la Interfaz de Usuario y Cambio de Bibliotecas
El renderizador convierte la carga en una interfaz de usuario llamando recursivamente a React CreateElement. La interfaz de usuario se actualiza según las entradas del usuario a través del proxy onChange. React Reconciler se encarga de actualizar el árbol de componentes. Se pueden intercambiar diferentes bibliotecas de cliente y renderizadores siempre que se mantenga el contrato. Una demostración muestra cómo un script externo renderiza un formulario y utiliza APIs adicionales proporcionadas por Shopify.
Finalmente, el renderizador en el lado del host convierte la carga en una interfaz de usuario. Internamente, el renderizador se encarga de convertir cada nodo en el árbol de componentes llamando recursivamente a React CreateElement con la implementación y las props para cada hijo. Ahora que hemos cubierto cómo se renderiza la interfaz de usuario, te explicaré cómo se actualiza la interfaz de usuario según las entradas del usuario. Aquí tenemos un ejemplo de un script externo que renderiza un campo de texto con la prop value gestionada internamente mediante state. Cuando un usuario escribe en el campo de texto, se llama al proxy onChange, lo que activa el método setTextValue para actualizar el state dentro del worker. La prop value del campo de texto se actualiza con un nuevo valor de texto. Internamente, React Reconciler llama a la ruta remota para manejar la actualización de su árbol de componentes. Esto a su vez envía un mensaje actualizado a través del receptor en el host, lo que desencadena una actualización en su ruta interna. Finalmente, se llama al renderizador con la ruta actualizada que contiene la prop actualizada para el campo de texto, lo que resulta en la renderización de una interfaz de usuario.
Ahora que hemos cubierto cómo se construye Argo en la web utilizando React, hablaré sobre cómo se puede intercambiar React. Al mirar nuevamente el flujo de extremo a extremo para renderizar la interfaz de usuario, se pueden reemplazar algunas piezas. Se pueden utilizar diferentes bibliotecas de cliente para construir la interfaz de usuario en el script. Por ejemplo, la biblioteca Argo React se puede reemplazar con vanilla JS o Vue.js. De manera similar, se puede intercambiar el renderizador en el lado del host por otra implementación. React DOM se puede reemplazar con Swift o Kotlin o React Native. Es posible intercambiar las piezas siempre que se mantenga el contrato entre el sandbox de JavaScript y el host. Se envía la misma carga de renderizado con el árbol de componentes serializado sin importar qué biblioteca esté utilizando el script externo para construir la interfaz de usuario. De manera similar, no importa cómo se renderice la interfaz de usuario en el host, cuando una interacción del usuario en la interfaz de usuario provoque la llamada a un controlador en el script externo, el host activa el controlador a través de un proxy.
Ahora, mostraré una demostración rápida pregrabada de cómo todas las piezas funcionan juntas. Aquí tengo un script externo que renderiza un formulario y un banner en Shopify en la web y en iOS. Para este ejemplo, he habilitado la recarga en vivo, lo que nos permitirá ver la interfaz de usuario actualizada a medida que cambiamos nuestro código. Ahora, demostraré cómo podemos utilizar APIs adicionales proporcionadas por Shopify. La biblioteca proporciona ganchos útiles para hacer eso. Llamaremos al gancho de API use extension. Y desde la API, extraeremos el objeto Toast que contiene un método para mostrar un mensaje Toast. Ahora, todo lo que queremos hacer es mostrar el contenido de nuestro formulario en un mensaje Toast como una cadena JSON. Una vez que se actualice, podemos probar nuestro nuevo callback. Así que estoy completando el formulario. Y ahora, si presiono enviar, obtengo un mensaje Toast con los datos de mi formulario. También puedo hacer lo mismo en iOS.
Renderizado en iOS y Preguntas del Público
Observa que iOS ha renderizado el Selector como un componente Selector nativo. El mismo script externo se utiliza para renderizar contenido tanto en iOS como en la web. Nuestro objetivo fue construido teniendo en cuenta la flexibilidad y la seguridad. Es bueno ver a las personas dedicándose a diferentes pasatiempos durante la pandemia. Trish ha estado coleccionando planos de casas y jugando videojuegos. La carpintería es otro pasatiempo que he adoptado. Pasemos a las preguntas del público.
Observa que iOS ha renderizado el Selector como un componente Selector nativo. Y cuando enviamos, obtenemos un mensaje Toast, al igual que en la web. El mismo script externo se utiliza para renderizar contenido tanto en iOS como en la web. Y el contenido es exactamente como aparece el contenido nativo de Shopify. Así concluye la presentación. Nuestro objetivo fue construido teniendo en cuenta la flexibilidad y la seguridad. Espero que esta charla te haya permitido aprender más sobre cómo funciona. Gracias por ver.
Es bueno verte de nuevo. Entonces, gente, Trisha ha preguntado qué pasatiempos han adoptado durante la pandemia y parece que el 50% de ustedes ha comenzado a jugar video juegos o tal vez han jugado más video juegos. El 44% hace ejercicio, es bueno ver que las personas se mantienen saludables y hacen ejercicio. Sé que muchos desarrolladores tienden a no hacer ejercicio, así que es bueno ver que muchas personas lo están haciendo. Leer, por supuesto, genial. Es genial ver juegos de mesa, oh, me encanta eso. Y algunos planos de casas. Realmente es bueno ver a las personas invirtiendo en el aire fresco de su hogar. ¿Y tú, Trish? ¿Qué has estado haciendo? Como puedes ver en mi fondo, principalmente planos de casas. He recogido como unos 50 planos de casas desde que comenzó COVID. También video juegos, desearía haber hecho más ejercicio. Eso está en mi lista de tareas pendientes. Bueno, si tienes 50 planes, eso es uno por semana. Y eso implica mucho caminar y andar en bicicleta para obtener los planos, ¿verdad? Así que eso es un tipo de ejercicio. Oh sí, y caminar por la casa, regarlos, bajarlos, ya sabes, limpiarlos y regarlos. Sí, es mucho trabajo. Llevar toda esa agua. Exactamente. No, buen trabajo. Yo mismo he estado aprendiendo carpintería. No diría que soy bueno, pero hey, es algo diferente al desarrollo.
Using External Code for Rendering
Los web workers siempre han parecido magia negra, pero hemos logrado hacerlos nuestros. El concepto es permitir que cualquier código externo se renderice dentro de una aplicación principal. Queremos ejecutar código de terceros de forma segura y ejecutar comportamientos personalizados, renderizar una interfaz de usuario personalizada en nuestras propias aplicaciones. Nuestro objetivo es la flexibilidad, permitiendo que el host y el script externo elijan sus tecnologías preferidas.
Así que vamos a pasar a las preguntas del público y sí, espero que puedas brindar información sobre las cosas que quieren saber.
Para mí, los web workers siempre han parecido magia negra. Así que es genial ver que has logrado hacerlos tuyos.
La primera pregunta es de Sasha. ¿En qué contexto usarías esta estrategia? Es un concepto completamente nuevo para mí, así que sería bueno entender por qué querríamos usarlo.
Bueno, el concepto aquí es permitir que cualquier código externo se renderice dentro de una aplicación principal. En Shopify, tenemos diferentes aplicaciones que pueden ser ampliadas por desarrolladores de terceros. Entonces, los desarrolladores pueden construir sobre nuestra plataforma. Eso significa que queremos poder ejecutar su código de forma segura y luego hacer que ejecuten comportamientos personalizados, renderizar una interfaz de usuario personalizada en nuestras propias aplicaciones. Y un desafío adicional es que nuestras aplicaciones están escritas en muchos lenguajes diferentes. Podría estar construida en React Native, podría estar escrita en Kotlin o simplemente ser una aplicación web. Queremos que el mismo código externo esté escrito en un lenguaje familiar. Así que digamos que un desarrollador externo puede escribir en React y ese mismo código React puede renderizarse nativamente en todas nuestras plataformas. Entonces, la estrategia, supongo, sería la flexibilidad para ambos lados. El host puede elegir la tecnología que utiliza para renderizar y el script externo también puede elegir la tecnología en la que quiere escribir el código. Espero que eso lo aclare. Si Sasha no lo cree así, entonces puede unirse a ti en tu chat facial y tener una conversación. Sí.
La siguiente pregunta es de Thorne. Como continuación a la pregunta de Sasha, en realidad, esto parece excesivo para este ejemplo. ¿En qué situación es útil esto? Creo que ya has tocado ese tema. ¿O quieres ampliar tu respuesta? Sí. Supongo que el ejemplo que di puede ser simplista. Pero creo que ya lo he cubierto. Queremos flexibilidad. Queremos que el host use la tecnología que necesite para renderizar la interfaz de usuario y hemos construido un contrato. Lo mencioné en mi charla. Podemos intercambiar las piezas y la tecnología que se utiliza puede intercambiarse siempre que se siga el contrato. Genial.
La siguiente pregunta es de nuestro usuario, visitante, Solal.
Argo y Código Externo
En nuestro caso, el código es externo y proporcionado por diferentes desarrolladores. Debe ejecutarse de forma segura, por lo que no podemos simplemente importar módulos. Hemos construido una plataforma que permite a los desarrolladores enviar y versionar su código. Renderizamos su código en Shopify, creando una separación adicional de nuestro propio código.
¿Por qué Argo en lugar de módulos federados modules si podemos usar un módulo federado? Correcto. Entonces, para nuestro caso particular, el código es externo, proporcionado por diferentes desarrolladores. Y debe ejecutarse de forma segura. Por lo tanto, no podemos simplemente importar modules. Es un requisito adicional que hemos construido una plataforma para permitir a los desarrolladores enviar su código a nosotros, pero también pueden versionarlo y volver a versiones anteriores. Por lo tanto, ellos mismos gestionan esa parte. Y en Shopify, simplemente renderizamos su código. Es como una separación adicional básicamente. Por lo tanto, no estamos importando código que hayamos escrito nosotros mismos. Todo esto es externo.
Motivación y Ventajas de la Renderización Remota
La motivación detrás de usar un renderizador remoto es principalmente la seguridad y la flexibilidad. El script externo se ejecuta en un sandbox separado con fines de seguridad. El rendimiento es un beneficio adicional. El uso de un worker proporciona una separación entre la aplicación principal y el sandbox, garantizando la seguridad. Las ventajas de usar el worker incluyen seguridad y mantener el control sobre el código externo.
Muy bien. La siguiente pregunta es de P. Tarek. ¿Cuál es el punto de usar un renderizador remoto? ¿Y cuál es la motivación detrás de ello? ¿Se trata de obtener performance en el hilo principal? Entonces, la motivación es principalmente seguridad y flexibilidad. Bien, bastante justo. Así que hay un sandbox en el que se ejecuta el script externo que está separado del hilo principal. Y luego, básicamente, podemos exponer diferentes APIs según lo consideremos adecuado para ese sandbox externo. Así que hay una separación que hemos creado por seguridad. Y a veces supongo que el rendimiento es una bonificación gratuita que se obtiene mientras se implementa por seguridad. Sí. Esa es la motivación detrás de ello. Principalmente es seguridad. Sí. Puedo imaginar que esa es la fuerza impulsora en tu empresa para la mayoría de las decisiones tecnológicas, seguridad. Sí. Como mencioné, todo es código externo. Queremos permitir flexibilidad, pero también mantener el control sobre lo que ese código podría hacer. Así es como hemos logrado que funcione. Genial. Impresionante.
La siguiente pregunta es de Nippuna777. ¿Cuáles son las ventajas de usar el worker aquí en lugar de hacerlo en la propia aplicación? Sí. Creo que mencioné esto. Queremos una separación entre la aplicación principal y el sandbox básicamente en el que se puede ejecutar el script externo. Genial. Entonces, nuevamente, seguridad. Nuevamente, seguridad. Siguiente pregunta. Esta parece la misma pregunta. Esta es de Sosia.
Implementación de React Native y Host
React Native es solo una tecnología que podemos elegir para implementar el host. La carga de la interfaz de usuario proviene del sandbox al host para su renderización en el lado del cliente. Si el host está inactivo, toda la aplicación estaría inactiva. El esfuerzo para configurar esta arquitectura fue significativo, con Kris Helvé sentando las bases y nuestro equipo construyendo a su alrededor.
¿Alguna vez se usaría en React Native o solo en la web? Sí. Esa es una buena pregunta. La belleza de construir este marco es que React Native es solo una tecnología que podemos elegir para implementar el host. Entonces, dependiendo de cómo se haya creado la aplicación principal de Shopify, podemos comenzar a desarrollar en React Native. Entonces, algunas de nuestras aplicaciones están escritas en React Native, la aplicación de la tienda lo está, por lo que ese es un lugar donde, si queremos ofrecer extensiones, podemos escribir la implementación utilizando React Native.
Genial. Esto es realmente poderoso. La siguiente pregunta es de John B. Él pregunta, sé que Angular o Blazor permiten la renderización en el lado del servidor, ¿es esta una implementación de renderización en React? En realidad, todo sucede en el navegador, en el cliente. Lo siento, no en el navegador. No diría eso, está sucediendo en el cliente. Entonces, en realidad no es una renderización en el lado del servidor. Entonces, la interfaz de usuario, básicamente, una carga proviene del sandbox y luego el host toma esa carga y renderiza la interfaz de usuario real. Por lo tanto, todo sucede en el lado del cliente.
De acuerdo, luego Paolo Henrique pregunta, pero ¿qué sucede si el host está inactivo? Sí, en este caso, si el host, que es la aplicación principal, está inactivo, entonces toda la aplicación estaría inactiva y nada se renderizaría. Entonces, sí, esto es como scripts externos que se conectan a una aplicación existente. Entonces, si la aplicación existente no se ejecuta, entonces básicamente todos los componentes o piezas externas tampoco se ejecutarían. En cualquier lado.
De acuerdo, tenemos tiempo para algunas preguntas más. Así que pasemos a la siguiente de Werner Bafa. ¿Cuál fue el esfuerzo para configurar toda esta arquitectura? Esa va a ser una respuesta loca, supongo. Sí, en realidad me gustaría dar un reconocimiento a Kris Helvé. Él es el autor de Remote UI. Esta es una biblioteca de código abierto. Puedes visitar el repositorio en GitHub. Kris Helvé estableció como una especie de base y nuestro equipo construyó las piezas a su alrededor. Así que fue un esfuerzo realmente grande porque tuvimos que pensar en muchas cosas como asegurarnos de lo que exponemos a los desarrolladores de terceros se pueda extender y personalizar según la aplicación en la que se están extendiendo. Como mencioné antes, Shopify tiene una gran cantidad de aplicaciones diferentes para diferentes propósitos. Así que necesitábamos que esto fuera flexible. Pero sí, el esfuerzo es difícil de cuantificar, pero Kris Helvé sentó las bases y luego muchas personas utilizaron esa base para construir todas estas piezas.
Proyecto de código abierto y compatibilidad con el navegador IE
Este proyecto fue construido teniendo en cuenta el código abierto, permitiendo que cualquier persona acceda y utilice la biblioteca. Ya está en producción en Shopify, ofreciendo estabilidad en algunos productos y con planes de expansión futura. El equipo detrás de este proyecto es grande y habrá más extensiones de Argo en el futuro. En cuanto al uso de este enfoque con el navegador IE, solo admitimos Edge. El lado de renderización es similar a la construcción de un sitio web y garantizamos la compatibilidad aprovechando el marco de interfaz de usuario Polaris.
¿Y este fue un proyecto de código abierto o Kris es un empleado de Shopify que luego, después de construirlo para Shopify, lo hizo de código abierto? Creo, no sé, Kris sería la mejor persona para responder esto, pero siempre se construyó teniendo en cuenta el código abierto. Cualquiera puede ir al sitio y obtener la biblioteca y construir cosas a su alrededor. Pero quiero decir, él es un empleado de Shopify. Sí, lo siento, Kris Helvé trabaja en Shopify. Sí, muchas de nuestras bibliotecas, intentamos contribuir de vuelta a la comunidad de código abierto. Y esta es una de ellas.
De acuerdo, genial, genial. Gracias y Shopify. La siguiente pregunta es de Zex, ¿este enfoque ya está en producción y en las aplicaciones de producción de Shopify y durante cuánto tiempo? Sí, está en producción. Ofrecemos un cierto grado de estabilidad en algunos de nuestros productos y luego ofreceremos más y más en el futuro. Está en vivo. Lo lanzamos, creo que fue en octubre pasado y habrá muchos más, los llamamos extensiones de Argo, en diferentes lugares de Shopify. Así que habrá más cosas que ver el próximo año. Tal vez vuelvas a dar una charla el próximo año sobre cómo funciona esto. O alguien más tenga la oportunidad. Tenemos un gran equipo construyendo esto. No solo soy yo. Sí, de acuerdo. Para nosotros, ahora eres la cara pero, por supuesto, hay un equipo detrás.
Siguiente pregunta. Y la última pregunta, desafortunadamente solo tenemos tiempo para una. Es una pregunta difícil. Es de Nikhil Bittekar. ¿Alguna lección aprendida al usar esto con el navegador IE? Oh, veo que para el navegador IE, solo admitimos Edge, por lo que no hay ninguna lección aprendida. Supongo que el lado de la renderización, es igual que construir un sitio web. Debes asegurarte de que funcione. Afortunadamente para nosotros, la extensibilidad que elegimos ofrecer está en una de nuestras aplicaciones llamada Shopify admin, que está construida utilizando Polaris. Es un marco de interfaz de usuario con componentes de interfaz de usuario que han sido probados en diferentes navegadores. Así que obtuvimos eso de forma gratuita. Pero la construcción de todo el lado depende de dónde se muestre.
Desafíos y Conclusiones
Debes asegurarte de que funcione. Todo el lado de la web y Android e iOS tienen desafíos diferentes. Afortunadamente, pudimos usar Polaris, lo que nos ahorra mucho trabajo. Desafortunadamente, eso es todo el tiempo que puedo darte aquí. Si tienes más preguntas o quieres profundizar en Web Workers, únete a Trish en su chat espacial.
Debes asegurarte de que funcione. Así que todo el lado de la web, parte de él tiene que funcionar en diferentes navegadores, básicamente. Y Android e iOS tienen desafíos diferentes porque tienen que funcionar en el teléfono. Así que sí, depende. Tenemos que hacer que todo funcione.
Pero afortunadamente pudimos usar Polaris. Ahorra mucho trabajo, por supuesto.
Bueno, desafortunadamente, eso es todo el tiempo que puedo darte aquí en esta encantadora etapa. Pero gente, si tienen más preguntas para Trish o quieren profundizar en Web Workers, ella estará en su chat espacial. Así que Trish, muchas gracias por unirte a nosotros y espero verte de nuevo pronto. Y diviértete en tu sala de oradores en el chat espacial. Gracias por recibirme.
Comments