reactjs - example - react native flux

Reaccionar, Flujo, Estado y Tiendas.

Question

Me parece que la aplicación de ejemplo todo flux es un poco escasa, por lo que estoy tratando de orientarme por las cosas desarrollando una aplicación para aprender y experimentar.

La aplicación es un organizador de cesta de frutas de arrastrar y soltar. Tengo varias canastas que pueden tener varias piezas de fruta arrastradas entre ellas. Puede resaltar una fruta haciendo clic en ella y el último elemento arrastrado permanecerá resaltado.

Basado en esto tengo 3 tiendas:

• Tienda de frutas
• BasketStore
• AppStateStore - Para rastrear la última fruta pulsada y la última vez que se arrastra

Cuando se produce una acción del usuario, AppStateStore envía y maneja FruitAction si se ha hecho clic en la fruta o en todas las tiendas si la fruta se ha movido a otra cesta.

El componente principal de AppView escucha para cambiar eventos tanto de FruitStore como de AppStateStore y se vuelve a representar.

Mis preguntas son:

• ¿Es este un buen enfoque para este escenario?
• ¿Debería la AppView escuchar múltiples tiendas? ¿Cómo debo evitar que el AppView se reproduzca varias veces seguidas? En este momento, cuando se ha movido una fruta, tanto FruitStore como AppStateStore provocan eventos de cambio que causan dos rendimientos en una fila.
• El artículo de Flux en el sitio de React muestra la vista enviando un objeto de acción (por ejemplo, AppDispatcher.dispatch (TodoActions.updateText ())) pero sería mejor si la acción se despachara (por ejemplo, solo FruitActions.moveBasket ()) y AppView es ¿No te has dado cuenta del AppDispatcher?
• Actualmente, solo AppView escucha las tiendas, pero ¿deberían los componentes de Fruit individuales escuchar la AppStateStore para volver a renderizarse solo si se deben resaltar?
• ¿Hay un ejemplo más completo de la arquitectura de Flux o algo similar?

Answer 1

Es difícil decir si el enfoque es bueno sin entender un poco más la aplicación.

Sin embargo, me parece que hacer clic en la fruta debe ser manejado por FruitStore. Es decir, una fruta ha ganado un estado activo, se ha vuelto arrastrable. Si esto afecta a la aplicación en su totalidad de alguna manera, entonces quizás esto también cause un cambio en el AppStateStore. Del mismo modo, mover una fruta de una cesta a otra parece ser el dominio de BasketStore.

Me imagino que FruitStore contiene una estructura de datos privada como esta:

var _fruit = {
1234: {
id: ''1234'',
type: ''apple'',
active: false
},
2345: {
id: ''2345'',
type: ''orange'',
active: false
},
3456: {
id: ''3456'',
type: ''apple'',
active: false
}
};

e imagino que BasketStore tiene una estructura de datos privada que se parece a esto:

var _baskets = {
4321: {
id: ''4321'',
name: ''Josephine/'s Basket'',
fruitIDs: [
1234,
2345
]
},
5432: {
id: ''5432'',
name: ''Harold/'s Basket'',
fruitIDs: [
3456
]
}
};

De este modo, FruitStore gestiona el estado "activo" de la fruta, y el contenido de las cestas lo gestiona BasketStore.

Por lo tanto, AppView puede escuchar ambas tiendas, si esto funciona bien para su aplicación. Y como se mencionó anteriormente, hay un costo muy pequeño por llamar repetidamente al método render (). Esto no afecta al DOM en cada llamada, esta es una de las mayores fortalezas de React. En su lugar, React procesará de forma inteligente las llamadas y solo actualizará las partes "sucias" del DOM, si las hay.

Pero quizás desee que las canastas se conviertan en vistas de controlador. Si elige que su fruta sea la vista del controlador, asegúrese de limpiar a los oyentes en componentWillUnmount (), ya que el movimiento de la fruta de una cesta a otra puede requerir que se destruyan y se vuelvan a crear. Creo que escuchar en el nivel de la canasta tiene más sentido, pero, una vez más, no entiendo bien tu aplicación.

Para contestar su última pregunta:

¿Hay un ejemplo más completo de la arquitectura de Flux o algo similar?

Los ingenieros de Facebook están trabajando en un ejemplo de aplicación más compleja ahora que mostrará el uso de waitFor () y el almacenamiento persistente del lado del servidor. Esperamos lanzar eso pronto.

Answer 2

• El enfoque suena bastante sólido. Yo crearía acciones completamente diferentes para cada interacción, por ejemplo, FruitClicked y FruitDragged podrían ser acciones, y las tiendas vigilarían las que les interesan.
• AppView debería escuchar todas las tiendas de las que obtiene datos. Si llama a setState más de una vez en el mismo tick, React los fusionará de manera inteligente, por lo que en realidad no está setState más de una vez.

• El artículo en el sitio React habla de acciones que se envían a sí mismas en Creación de acciones semánticas . En el bloque de código que se encuentra a lo largo de la página, puede ver el código:

  _onDestroyClick: function() {
  TodoActions.destroy(this.props.todo.id);
  } 

• El artículo también habla sobre qué componentes deberían escuchar las tiendas en Cómo escuchar cambios con una vista de controlador :

  Necesitamos un componente React cerca de la parte superior de nuestra jerarquía de componentes para escuchar los cambios en la tienda. En una aplicación más grande, tendríamos más de estos componentes de escucha, tal vez uno para cada sección de la página. En la Herramienta de creación de anuncios de Facebook, tenemos muchas de estas vistas similares a las de un controlador, cada una de las cuales rige una sección específica de la interfaz de usuario. En el editor de video Lookback, solo teníamos dos: uno para la vista previa animada y otro para la interfaz de selección de imágenes.

  y

  En ocasiones, es posible que tengamos que agregar vistas de controlador adicionales más profundas en la jerarquía para mantener los componentes simples. Esto podría ayudarnos a encapsular mejor una sección de la jerarquía relacionada con un dominio de datos específico. Sin embargo, tenga en cuenta que las vistas de controlador más profundas en la jerarquía pueden violar el flujo singular de datos al introducir un nuevo punto de entrada potencialmente conflictivo para el flujo de datos. Al tomar la decisión de agregar una vista de controlador profunda, equilibre la ganancia de componentes más simples contra la complejidad de las múltiples actualizaciones de datos que fluyen en la jerarquía en diferentes puntos. Estas actualizaciones de datos múltiples pueden llevar a efectos extraños, ya que las actualizaciones de diferentes vistas de controlador invocan repetidamente el método de renderizado de React, lo que podría aumentar la dificultad de la depuración.

• Si está interesado en la arquitectura de flujo, es posible que esté interesado en Fluxxor (descargo de responsabilidad: lo escribí), que (con suerte) ayuda a desarrollar una aplicación basada en flujo. Tiene un despachador que es un poco más robusto y algunos otros cambios (por ejemplo, acciones / almacenes no globales, reactores mixtos) para hacer las cosas un poco más fáciles en muchos casos.