¿Recuerdas que siempre decimos que la programación es como Taco Bell? ¡Siempre son los mismos ingredientes utilizados de una manera diferente! En este caso particular, vamos a confiar mucho en los Eventos para crear toda la arquitectura de la aplicación.
Sabemos que todavía estás aprendiendo React. Los states (estados) y las props (propiedades) pueden ser confusos, y ahora, con Flux, las cosas se van a poner un poco más difíciles ¡Pero es por una buena causa!
Sin Flux, no puedes crear aplicaciones React medianas o grandes porque todo se desorganizará bastante rápido.
Además, dos vistas diferentes no pueden enviar datos entre sí como lo hacen los componentes (utilizando props) porque todas las vistas son parientes y React Router las está instanciando. Necesitamos tener un store común compartido entre todas las vistas que vamos a llamar "The Store"
Aquí hay una lista de todas las ventajas de usarlo:
Vistas/Views (Components) | Cada componente React que llama a cualquier acción Flux es llamada una vista. La razón para llamar a esos componentes de una manera diferente es porque se supone que los componentes de React se comunican entre sí a través de sus accesorios (sin Flux). Una vez que un componente React esté vinculado de forma rígida a Flux, no podrá reutilizar ese componente en el futuro (en este o en cualquier otro desarrollo). |
Acciones (Actions) | Las acciones pueden ser activadas por componentes (cuando el usuario hace clic o interactúa con la aplicación) o por el sistema (por ejemplo, la funcionalidad de guardado automático). Las acciones son el primer paso de cualquier flujo de trabajo de Flux y siempre deben enviarse al Store. |
Store | El store contiene todos los datos de la aplicación. Maneja todo lo que recibe el despachador y determina la forma en que se deben almacenar y recuperar los datos. |
El siguiente proyecto es una aplicación de To-Do List (lista de tareas) con 2 historias de usuario principales:
Para codificar la función para eliminar tareas, tenemos que actualizar 4 archivos principales: (1) El Componente (The Component) (para cuando el usuario haga clic), (2) las Acciones (The Actions), (3) El Store (dos veces), y, (4) el Componente (The Component) una última vez. Son solo 3 archivos y 5 actualizaciones. Y tienes que hacer eso para cada historia de usuario que vayas a construir en tu aplicación.
Al final, trabajar con Flux tiene que convertirse en algo tan automático como andar en bicicleta.
(Siempre es un evento típico de JS como: hacer clic, on hover, cambiar el tamaño, etc.)
Todo comienza cuando el usuario debe hacer clic en el icono de la papelera. Es por eso que necesitamos iniciar nuestra aplicación escuchando el típico evento onClick en el botón de eliminar.
1 2// En el componente que representa cada elemento de tarea, debemos agregar un botón y también un sensor onClik que llame 3 4// a la respectiva función TodoAction.deleteTodo(task) que crearemos en las acciones: 5 6<button onClick={()=>MyActions.deleteTodo(taskToDelete)}>delete</button>
1MyActions.js 2 3// En este caso, decidimos que esta función (conocida como action) recibirá el ID de la tarea que se eliminará. 4class MyActions extends Flux.Actions{ 5 deleteTask(taskToDelete){ 6 //obtiene la lista actual de acciondes del store 7 let currentActions = MyStore.getActions(); 8 let updatedActions = currentActions.filter((task) => { 9 return (task.id != taskToDelete.id); 10 }); 11 12 this.dispatch('MyStore.setActions', updatedActions); 13 } 14}
☝️ Este es un componente de clase. Te recomendamos que uses componentes funcionales y hooks en su lugar ya que lo componentes de clase están considerados como legacy(deprecados).
1// Dentro de todoStore tenemos un método HandleActions que contiene la lógica para manejar cada acción distribuida. 2// Tenemos que agregar un nuevo caso al switch con el nombre 'DELETE_TODO' 3// Tiene que coincidir con el nombre de la acción que se envió. 4 5handleActions(action) { 6 switch (action.type) { 7 ... 8 case 'DELETE_TODO': { 9 this.deleteTodo(action.id); 10 break; 11 } 12 } 13}
1 2// En cualquier lugar de tu clase TodoStore, agrega un nuevo método que finalmente elimine la tarea del to-do list. 3// En este caso estamos usando la función de filter porque devuelve el mismo array pero sólo con 4// los elementos que coinciden con la pregunta lógica dentro del filtro (task.id! = id) 5 6class TodoStore extends EventEmitter { 7 ... 8 deleteTodo(id){ 9 this.todos = this.todos.filter((task)=>{ 10 //filtra todas las tareas que tienen el id dado 11 return (task.id != id); 12 }); 13 this.emit('change'); 14 } 15 ... 16}
☝️ Este es un componente de clase. Te recomendamos que uses componentes funcionales y hooks en su lugar ya que lo componentes de clase están considerados como legacy (deprecados).
Finalmente, tenemos una nueva función implementada en nuestro proyecto. Para seguir agregando más funciones, sólo tienes que iniciar de nuevo el flujo de trabajo de codificación de Flux desde el paso 1.