Estrategias para la representación del lado del servidor de componentes React.js inicializados asincrónicamente

114

Se supone que una de las mayores ventajas de React.js es la renderización del lado del servidor . El problema es que la función clave React.renderComponentToString()es síncrona, lo que hace que sea imposible cargar datos asincrónicos cuando la jerarquía de componentes se representa en el servidor.

Digamos que tengo un componente universal para comentar que puedo colocar prácticamente en cualquier lugar de la página. Tiene solo una propiedad, algún tipo de identificador (por ejemplo, la identificación de un artículo debajo del cual se colocan los comentarios), y todo lo demás lo maneja el componente mismo (cargar, agregar, administrar comentarios).

Me gusta mucho la arquitectura Flux porque hace muchas cosas mucho más fáciles y sus tiendas son perfectas para compartir el estado entre el servidor y el cliente. Una vez que se inicializa mi tienda que contiene comentarios, puedo serializarla y enviarla del servidor al cliente, donde se puede restaurar fácilmente.

La pregunta es cuál es la mejor manera de poblar mi tienda. Durante los últimos días he estado buscando mucho en Google y me he encontrado con pocas estrategias, ninguna de las cuales me pareció realmente buena considerando cuánto se está "promocionando" esta característica de React.

  1. En mi opinión, la forma más sencilla es llenar todas mis tiendas antes de que comience la renderización real. Eso significa en algún lugar fuera de la jerarquía de componentes (conectado a mi enrutador, por ejemplo). El problema con este enfoque es que tendría que definir prácticamente dos veces la estructura de la página. Considere una página más compleja, por ejemplo, una página de blog con muchos componentes diferentes (publicación de blog real, comentarios, publicaciones relacionadas, publicaciones más recientes, flujo de Twitter ...). Tendría que diseñar la estructura de la página usando componentes de React y luego en otro lugar tendría que definir el proceso de poblar cada tienda requerida para esta página actual. Eso no me parece una buena solución. Desafortunadamente, la mayoría de los tutoriales isomórficos están diseñados de esta manera (por ejemplo, este gran tutorial de flujo ).

  2. React-async . Este enfoque es perfecto. Me permite simplemente definir en una función especial en cada componente cómo inicializar el estado (no importa si de forma sincrónica o asincrónica) y estas funciones se llaman cuando la jerarquía se representa en HTML. Funciona de tal manera que un componente no se procesa hasta que el estado se inicializa por completo. El problema es que requiere Fibrasque es, hasta donde tengo entendido, una extensión de Node.js que altera el comportamiento estándar de JavaScript. Aunque me gusta mucho el resultado, me sigue pareciendo que en lugar de encontrar una solución cambiamos las reglas del juego. Y creo que no deberíamos vernos obligados a hacer eso para usar esta característica principal de React.js. Tampoco estoy seguro del soporte general de esta solución. ¿Es posible utilizar Fiber en el alojamiento web estándar de Node.js?

  3. Estaba pensando un poco por mi cuenta. Realmente no he pensado en los detalles de implementación, pero la idea general es que ampliaría los componentes de manera similar a React-async y luego llamaría repetidamente a React.renderComponentToString () en el componente raíz. Durante cada pase, recopilaba las devoluciones de llamada extendidas y luego las llamaba al y del pase para llenar las tiendas. Repetiría este paso hasta que se llenen todas las tiendas requeridas por la jerarquía de componentes actual. Hay muchas cosas por resolver y estoy particularmente inseguro sobre el rendimiento.

¿Me he perdido algo? ¿Existe otro enfoque / solución? En este momento estoy pensando en ir por el camino react-async / fiber, pero no estoy completamente seguro como se explica en el segundo punto.

Discusión relacionada en GitHub . Aparentemente, no existe un enfoque oficial ni siquiera una solución. Quizás la verdadera pregunta es cómo se pretende que se utilicen los componentes de React. ¿Como una capa de vista simple (más o menos mi sugerencia número uno) o como componentes reales independientes e independientes?

tobik
fuente
Solo para entender las cosas: ¿las llamadas asincrónicas también ocurrirían en el lado del servidor? No entiendo los beneficios en este caso en comparación con renderizar la vista con algunas partes vacías y llenarla a medida que llegan los resultados de la respuesta asincrónica. Probablemente falta algo, ¡lo siento!
phtrivier
No debe olvidar que en JavaScript, incluso la consulta más simple a la base de datos para obtener las últimas publicaciones es asincrónica. Entonces, si está renderizando una vista, debe esperar hasta que los datos se obtengan de la base de datos. Y hay beneficios obvios de renderizar en el lado del servidor: SEO por ejemplo. Y también evita que la página parpadee. En realidad, la representación del lado del servidor es el enfoque estándar que todavía utilizan la mayoría de los sitios web.
tobik
Claro, pero ¿está intentando representar la página completa (una vez que hayan respondido todas las consultas asincrónicas de la base de datos)? En cuyo caso, lo habría separado ingenuamente como 1 / obtener todos los datos de forma asincrónica 2 / cuando haya terminado, pasarlo a una vista de reacción "tonta" y responder a la solicitud. ¿O está tratando de hacer ambas renderizaciones del lado del servidor, luego del lado del cliente con el mismo código (y necesita que el código asíncrono esté cerca de la vista de reacción?) Lo siento si eso suena tonto, simplemente no estoy seguro de entender que estas haciendo.
phtrivier
No hay problema, quizás otras personas también tengan problemas para entender :) Lo que acaba de describir es la solución número dos. Pero tomemos, por ejemplo, el componente para comentar de la pregunta. En la aplicación común del lado del cliente, podría hacer todo en ese componente (cargar / agregar comentarios). El componente estaría separado del mundo exterior y el mundo exterior no tendría que preocuparse por este componente. Sería completamente independiente y autónomo. Pero una vez que quiero introducir la representación del lado del servidor, tengo que manejar las cosas asincrónicas afuera. Y eso rompe todo el principio.
tobik
Para que quede claro, no estoy abogando por el uso de fibras, sino solo por hacer todas las llamadas asíncronas y, una vez que estén todas terminadas (usando la promesa o lo que sea), renderice el componente en el lado del servidor. (Por lo tanto, los componentes de reacción no sabrían en absoluto sobre las cosas asincrónicas). Ahora, eso es solo una opinión, pero en realidad me gusta la idea de eliminar por completo todo lo relacionado con la comunicación del servidor de los componentes de React (que en realidad solo están aquí para representar la vista .) Y creo que esa es la filosofía detrás de reaccionar, lo que podría explicar por qué lo que estás haciendo es un poco complicado. De todos modos, buena suerte :)
phtrivier

Respuestas:

15

Si utiliza react-enrutador , simplemente puede definir un willTransitionTométodo en los componentes, que obtiene un Transitionobjeto al que puede llamar .wait.

No importa si renderToString es síncrono porque la devolución de llamada a Router.runno se llamará hasta que .waitse resuelvan todas las promesas de ed, por lo que para cuando renderToStringse llame en el middleware, podría haber llenado las tiendas. Incluso si las tiendas son singleton, puede configurar sus datos temporalmente justo a tiempo antes de la llamada de renderizado síncrono y el componente lo verá.

Ejemplo de middleware:

var Router = require('react-router');
var React = require("react");
var url = require("fast-url-parser");

module.exports = function(routes) {
    return function(req, res, next) {
        var path = url.parse(req.url).pathname;
        if (/^\/?api/i.test(path)) {
            return next();
        }
        Router.run(routes, path, function(Handler, state) {
            var markup = React.renderToString(<Handler routerState={state} />);
            var locals = {markup: markup};
            res.render("layouts/main", locals);
        });
    };
};

El routesobjeto (que describe la jerarquía de rutas) se comparte literalmente con el cliente y el servidor.

Esailija
fuente
Gracias. El caso es que, hasta donde yo sé, solo los componentes de ruta admiten este willTransitionTométodo. Lo que significa que todavía no es posible escribir componentes reutilizables completamente independientes como el que describí en la pregunta. Pero a menos que estemos dispuestos a optar por Fibers, esta es probablemente la mejor y más eficaz forma de implementar el renderizado del lado del servidor.
tobik
Esto es interesante. ¿Cómo sería una implementación del método willTransitionTo para tener datos asíncronos cargados?
Hyra
Obtendrá el transitionobjeto como parámetro, por lo que simplemente llamará transition.wait(yourPromise). Eso, por supuesto, significa que debe implementar su API para respaldar las promesas. Otra desventaja de este enfoque es que no existe una forma sencilla de implementar un "indicador de carga" en el lado del cliente. La transición no cambiará al componente del controlador de ruta hasta que se resuelvan todas las promesas.
tobik
Pero en realidad no estoy seguro acerca del enfoque "justo a tiempo". Varios controladores de ruta anidados pueden coincidir con una URL, lo que significa que se deberán resolver varias promesas. No hay garantía de que todos terminen al mismo tiempo. Si las tiendas son singleton, puede causar conflictos. @Esailija ¿podrías explicar un poco tu respuesta?
tobik
Tengo una plomería automática en su lugar que recopila todas las promesas .waitedde una transición. Una vez que se cumplen todos, .runse llama a la devolución de llamada. Justo antes de .render()recopilar todos los datos de las promesas y establecer los estados de la tienda singelton, luego en la siguiente línea después de la llamada de procesamiento, inicializo las tiendas singleton. Es bastante complicado, pero todo sucede automáticamente y el componente y el código de la aplicación de la tienda se mantienen prácticamente iguales.
Esailija
0

Sé que probablemente esto no sea exactamente lo que desea, y puede que no tenga sentido, pero recuerdo haberme arreglado modificando ligeramente el componente para manejar ambos:

  • renderizado en el lado del servidor, con todo el estado inicial ya recuperado, de forma asincrónica si es necesario)
  • renderizado en el lado del cliente, con ajax si es necesario

Entonces algo como:

/** @jsx React.DOM */

var UserGist = React.createClass({
  getInitialState: function() {

    if (this.props.serverSide) {
       return this.props.initialState;
    } else {
      return {
        username: '',
        lastGistUrl: ''
      };
    }

  },

  componentDidMount: function() {
    if (!this.props.serverSide) {

     $.get(this.props.source, function(result) {
      var lastGist = result[0];
      if (this.isMounted()) {
        this.setState({
          username: lastGist.owner.login,
          lastGistUrl: lastGist.html_url
        });
      }
    }.bind(this));

    }

  },

  render: function() {
    return (
      <div>
        {this.state.username}'s last gist is
        <a href={this.state.lastGistUrl}>here</a>.
      </div>
    );
  }
});

// On the client side
React.renderComponent(
  <UserGist source="https://api.github.com/users/octocat/gists" />,
  mountNode
);

// On the server side
getTheInitialState().then(function (initialState) {

    var renderingOptions = {
        initialState : initialState;
        serverSide : true;
    };
    var str = Xxx.renderComponentAsString( ... renderingOptions ...)  

});

Lo siento, no tengo el código exacto a mano, por lo que es posible que esto no funcione, pero lo estoy publicando en aras de la discusión.

Una vez más, la idea es tratar a la mayor parte del componente como una vista mudo, y hacer frente a traer los datos tanto como sea posible fuera del componente.

phtrivier
fuente
1
Gracias. Entiendo la idea, pero en realidad no es lo que quiero. Digamos que quiero construir un sitio web más complejo usando React, como bbc.com . Al mirar la página, puedo ver "componentes" en todas partes. Una sección (deporte, negocios ...) es un componente típico. ¿Cómo lo implementaría? ¿Dónde buscaría previamente todos los datos? Para diseñar un sitio tan complejo, los componentes (como principio, como pequeños contenedores MVC) son muy buenos (si tal vez el único) camino a seguir. El enfoque de componentes es común para muchos marcos típicos del lado del servidor. La pregunta es: ¿puedo usar React para eso?
tobik
Precargará los datos en el lado del servidor (como probablemente se hace en este caso, antes de pasarlos a un sistema de plantillas del lado del servidor "tradicional"); sólo porque la visualización de los datos se beneficia de ser modular, ¿significa que el cálculo de los datos debe seguir necesariamente la misma estructura? Estoy jugando un poco al abogado del diablo aquí, tuve el mismo problema que tienes cuando revisas om. Y espero que alguien tenga más conocimientos sobre esto que yo; componer cosas sin problemas en cualquier lado del cable ayudaría mucho.
phtrivier
1
Por dónde me refiero a dónde en el código. ¿En el controlador? Entonces, ¿el método del controlador que maneja la página de inicio de bbc contendría como una docena de consultas similares, para cada sección uno? En mi humilde opinión, es un camino al infierno. Así que sí, yo hago pensar que el cálculo debe ser modular también. Todo empaquetado en un componente, en un contenedor MVC. Así es como desarrollo aplicaciones estándar del lado del servidor y estoy bastante seguro de que este enfoque es bueno. Y la razón por la que estoy tan emocionado con React.js es que existe un gran potencial para usar este enfoque tanto en el lado del cliente como en el del servidor para crear aplicaciones isomórficas increíbles.
tobik
1
En cualquier sitio (grande / pequeño), solo tiene que renderizar en el lado del servidor (SSR) la página actual con su estado de inicio; no necesita el estado de inicio para cada página. El servidor toma el estado de inicio, lo renderiza y lo pasa al cliente <script type=application/json>{initState}</script>; de esa forma los datos estarán en el HTML. Rehidrate / vincule eventos de IU a la página llamando a render en el cliente. Las páginas posteriores son creadas por el código js del cliente (obteniendo datos según sea necesario) y representadas por el cliente. De esa manera, cualquier actualización cargará páginas SSR nuevas y hacer clic en una página será CSR. = isomorfo y compatible con SEO
Federico
0

Realmente me he metido con esto hoy, y aunque esto no es una respuesta a su problema, he utilizado este enfoque. Quería usar Express para enrutamiento en lugar de React Router, y no quería usar Fibers ya que no necesitaba soporte de subprocesos en node.

Así que acabo de tomar la decisión de que, para los datos iniciales que deben presentarse en el almacén de flujo en carga, realizaré una solicitud AJAX y pasaré los datos iniciales al almacén.

Estaba usando Fluxxor para este ejemplo.

Entonces, en mi ruta rápida, en este caso una /productsruta:

var request = require('superagent');
var url = 'http://myendpoint/api/product?category=FI';

request
  .get(url)
  .end(function(err, response){
    if (response.ok) {    
      render(res, response.body);        
    } else {
      render(res, 'error getting initial product data');
    }
 }.bind(this));

Luego, mi método de procesamiento de inicialización que pasa los datos a la tienda.

var render = function (res, products) {
  var stores = { 
    productStore: new productStore({category: category, products: products }),
    categoryStore: new categoryStore()
  };

  var actions = { 
    productActions: productActions,
    categoryActions: categoryActions
  };

  var flux = new Fluxxor.Flux(stores, actions);

  var App = React.createClass({
    render: function() {
      return (
          <Product flux={flux} />
      );
    }
  });

  var ProductApp = React.createFactory(App);
  var html = React.renderToString(ProductApp());
  // using ejs for templating here, could use something else
  res.render('product-view.ejs', { app: html });
svnm
fuente
0

Sé que esta pregunta se hizo hace un año, pero tuvimos el mismo problema y lo resolvemos con promesas anidadas que se derivaron de los componentes que se van a renderizar. Al final, teníamos todos los datos de la aplicación y simplemente los enviamos.

Por ejemplo:

var App = React.createClass({

    /**
     *
     */
    statics: {
        /**
         *
         * @returns {*}
         */
        getData: function (t, user) {

            return Q.all([

                Feed.getData(t),

                Header.getData(user),

                Footer.getData()

            ]).spread(
                /**
                 *
                 * @param feedData
                 * @param headerData
                 * @param footerData
                 */
                function (feedData, headerData, footerData) {

                    return {
                        header: headerData,
                        feed: feedData,
                        footer: footerData
                    }

                });

        }
    },

    /**
     *
     * @returns {XML}
     */
    render: function () {

        return (
            <label>
                <Header data={this.props.header} />
                <Feed data={this.props.feed}/>
                <Footer data={this.props.footer} />
            </label>
        );

    }

});

y en el enrutador

var AppFactory = React.createFactory(App);

App.getData(t, user).then(
    /**
     *
     * @param data
     */
    function (data) {

        var app = React.renderToString(
            AppFactory(data)
        );       

        res.render(
            'layout',
            {
                body: app,
                someData: JSON.stringify(data)                
            }
        );

    }
).fail(
    /**
     *
     * @param error
     */
    function (error) {
        next(error);
    }
);
Rotem
fuente
0

Quiero compartir con ustedes mi enfoque del uso de renderización del lado del servidor Flux, por ejemplo:

  1. Digamos que tenemos componentcon los datos iniciales de la tienda:

    class MyComponent extends Component {
      constructor(props) {
        super(props);
        this.state = {
          data: myStore.getData()
        };
      }
    }
  2. Si la clase requiere algunos datos precargados para el estado inicial, creemos Loader para MyComponent:

     class MyComponentLoader {
        constructor() {
            myStore.addChangeListener(this.onFetch);
        }
        load() {
            return new Promise((resolve, reject) => {
                this.resolve = resolve;
                myActions.getInitialData(); 
            });
        }
        onFetch = () => this.resolve(data);
    }
  3. Tienda:

    class MyStore extends StoreBase {
        constructor() {
            switch(action => {
                case 'GET_INITIAL_DATA':
                this.yourFetchFunction()
                    .then(response => {
                        this.data = response;
                        this.emitChange();
                     });
                 break;
        }
        getData = () => this.data;
    }
  4. Ahora solo cargue los datos en el enrutador:

    on('/my-route', async () => {
        await new MyComponentLoader().load();
        return <MyComponent/>;
    });
zooblin
fuente
0

solo como un resumen breve -> GraphQL resolverá esto completamente para su pila ...

  • agregar GraphQL
  • usa apollo y react-apollo
  • use "getDataFromTree" antes de comenzar a renderizar

-> getDataFromTree encontrará automáticamente todas las consultas involucradas en su aplicación y las ejecutará, colocando su caché apollo en el servidor y, por lo tanto, habilitando SSR en pleno funcionamiento .. BÄM

jebbie
fuente