javascript - create - server side rendering react redux
¿Rendimiento de React+Flux y del servidor?(Isomorphic React+Flux) (4)
¿Cuál es la práctica general de establecer el estado inicial de la aplicación con aplicaciones isomórficas? Sin Flux, simplemente usaría algo como:
var props = { }; // initial state
var html = React.renderToString(MyComponent(props);
A continuación, renderice ese marcado a través express-handlebars y {{{reactMarkup}} través de {{{reactMarkup}} .
En el lado del cliente para establecer el estado inicial, haría algo como esto:
if (typeof window !== ''undefined'') {
var props = JSON.parse(document.getElementById(''props'').innerHTML);
React.render(MyComponent(props), document.getElementById(''reactMarkup''));
}
Así que, básicamente, usted está configurando el estado dos veces, en el servidor y en el cliente; sin embargo, React comparará las diferencias y en la mayoría de los casos, por lo que no afectará el rendimiento al volver a representar.
¿Cómo funcionaría este principio cuando tenga acciones y almacenes en la arquitectura Flux? Dentro de mi componente podría hacer:
getInitialState: function() {
return AppStore.getAppState();
}
Pero ahora, ¿cómo configuro el estado inicial en la AppStore desde el servidor? Si uso React.renderToString sin propiedades pasadas, se llamará a AppStore.getAppState() que no tendrá nada porque aún no entiendo cómo puedo configurar el estado en mi tienda en el servidor.
Actualización 5 de febrero de 2015
Todavía estoy buscando una solución limpia que no implique el uso de implementaciones de Flux de terceros como Fluxible, Fluxxor, Reflux .
Actualización 19 de agosto de 2016
Usa Redux .
Eche un vistazo a las bibliotecas relacionadas de dispatchr y yahoo.
La mayoría de las implementaciones de flujo no funcionan en node.js porque usan singleton almacenado, despachadores y acciones, y no tienen el concepto de "hemos terminado", que es necesario para saber cuándo renderizar a html y responder a la solicitud.
Las bibliotecas de Yahoo como fetchr y routr evitan esta limitación de nodo al usar una forma muy pura de inyección de dependencia (sin funciones de análisis para nombres de argumento ni nada de eso).
En su lugar, define funciones de API como esta en services/todo.js :
create: function (req, resource, params, body, config, callback) {
Y acciones como esta en actions/createTodo.js :
module.exports = function (context, payload, done) {
var todoStore = context.getStore(TodoStore);
...
context.dispatch(''CREATE_TODO_START'', newTodo);
...
context.service.create(''todo'', newTodo, {}, function (err, todo) {
La última línea llama indirectamente a la función de creación en services / todo.js. En este caso indirectamente puede significar:
- en el servidor:
- fetchr rellena los argumentos adicionales cuando estás en el servidor
- luego llama tu devolución de llamada
- en el lado del cliente:
- el cliente fetchr hace una solicitud http
- fetchr en el servidor lo intercepta
- llama a la función de servicio con los argumentos correctos
- envía la respuesta de vuelta al fetchr del cliente
- el fetchr del lado del cliente se encarga de llamar a su devolución de llamada
Esto es sólo la punta del iceberg. Este es un grupo muy sofisticado de módulos que trabajan en conjunto para resolver un problema difícil y proporcionar una API apta. El isomorfismo es intrínsecamente complicado en los casos de uso del mundo real. Esta es la razón por la cual muchas implementaciones de flujo no admiten el procesamiento del lado del servidor.
Es posible que también desee considerar no usar fundente. No tiene sentido para todas las aplicaciones y, a menudo, solo se interpone en el camino. La mayoría de las veces solo lo necesita para algunas partes de la aplicación, si corresponde. ¡No hay balas de plata en la programación!
El problema es que cuando buscas "representación del servidor Flux" , de inmediato te topas con esta pregunta y no hay mención de Redux , hecha por React.js community rackt . Puede encontrar muy bien descrito en la documentation de Redux por qué es importante la representación del servidor, por qué tenemos que enviar el estado inicial dentro del HTML al cliente (que es donde Flux no es suficiente) y cómo hacerlo.
FakeRainBrigand tiene razón en que el mayor problema con Flux del lado del servidor son los singletons. Flummox soluciona este problema al no usar singletons y le permite encapsular toda su configuración de Flux en una única clase reutilizable. Luego, solo crea una nueva instancia en cada solicitud. Combinado con una solución de enrutamiento como React Router, puede hacer aplicaciones completamente isomorfas.
Incluso si no quiere usar Flummox, la fuente es fácil de asimilar y podría usarla como guía para inventar algo usted mismo:
Si está dispuesto a trabajar con alt.js , puede hacerlo con alt.bootstrap y alt.flush ( docs )
Estoy utilizando el nodo js con la representación del lado del servidor de reacción y alt.js como mi implementación de flujo.
Así es como se ve:
var data = {}; // Get the data whatever you want and return it bootstrap ready.
// Reminder - renderToString is synchronised
var app = React.renderToString(
AppFactory(data)
);
// In this point the react rendering was finished so we can flush the data and reset the stores
alt.flush();
En mi app.jsx
/**
*
*/
componentWillMount: function () {
// This beauty here is that componentWillMount is run on the server and the client so this is all we need to do. No need for other third-party isomorphic frameworks
alt.bootstrap(
JSON.stringify(this.props, null, 3)
);
}