javascript - react - ¿Cómo elegir la forma de estado Redux para una aplicación con vistas de lista/detalle y paginación?

para que sirve redux

Question

Imagine que tengo varias entradas (por ejemplo, usuarios) en mi base de datos. También tengo dos rutas, una para la lista, otra para el detalle (donde puede editar la entrada). Ahora estoy luchando con cómo abordar la estructura de datos.

Estoy pensando en dos enfoques y una especie de combinación de ambos.

Conjunto de datos compartidos

• Navego a /list , todos mis usuarios se descargan de una API almacenada en la tienda redux, bajo los users clave, también agrego algún tipo de users_offset y users_limit para representar solo una parte de la lista
• Luego navego a /detail/<id> y almaceno currently_selected_user con <id> como val ... lo que significa que podré obtener los datos de mi usuario con algo como esto users.find(res => res.id === currently_selected_user)
• la actualización también será agradable y fácil, ya que estoy trabajando con un solo conjunto de datos y detalles apuntando a él
• agregar un nuevo usuario también es fácil, de nuevo solo trabajando con la misma lista de usuarios

Ahora, el problema que tengo con este enfoque es que, cuando la lista de usuarios se vuelve enorme (digamos millones), la descarga puede tardar un tiempo. Y también, cuando navegue directamente a /detail/<id> , todavía no tendré todos mis usuarios descargados, así que para obtener datos solo para el que necesito, primero tendré que descargar todo. Millones de usuarios solo para editar uno.

Conjunto de datos separados

• Navego a /list , y en lugar de descargar a todos mis usuarios de la API, solo descargo un par de ellos, dependiendo de lo que esté configurado my users_per_page y users_current_page , y probablemente almacene los datos como users_currently_visible
• Luego navego a /detail/<id> , almaceno currently_selected_user con <id> como el valor ... y en lugar de buscar en users_currently_visible simplemente descargo los datos del usuario desde api ..
• en la actualización, no voy a actualizar users_currently_visible de ninguna manera
• ni agregaré

Lo que veo como un posible problema aquí es que tendré que, al visitar /list , descargar datos de la API nuevamente, porque podría no estar sincronizado con lo que hay en la base de datos, también podría estar descargando innecesariamente los datos de los usuarios en detalle , porque pueden estar incidentalmente dentro de mis users_currently_visible

una especie de travesuras frankenstein-y

• Detallo, hago lo mismo que en el conjunto de datos separados, pero en lugar de descargar directamente los datos del usuario desde la API, primero verifico:
  • ¿Tengo algún users_currently_visible
  • Si es así, ¿hay un usuario con mi identificación entre ellos? si ambas son verdaderas, entonces las uso como mis datos de usuario, de lo contrario hago la llamada a la API
• lo mismo sucede en la actualización, compruebo si mi usuario existe entre users_currently_visible si es así, también actualizo esa lista, si no, no hago nada

Esto probablemente funcionaría, pero realmente no parece que sea la forma correcta. Probablemente también necesite descargar una lista nueva de users_currently_visible al visitar /list , porque podría haber agregado una nueva.

¿Hay alguna forma favorita de hacer esto para los fanáticos? ... Estoy seguro de que cada usuario de redux debe haber encontrado lo mismo.

¡Gracias!

Answer 1

Consulte el ejemplo del "mundo real" del repositorio de Redux.
Muestra la solución a exactamente este problema.

La forma de su estado debería verse así:

{
  entities: {
    users: {
      1: { id: 1, name: ''Dan'' },
      42: { id: 42, name: ''Mary'' }
    }
  },
  visibleUsers: {
    ids: [1, 42],
    isFetching: false,
    offset: 0
  }
}

Tenga en cuenta que estoy almacenando entities (ID -> Mapas de objetos) y visibleUsers (descripción de usuarios actualmente visibles con estado de paginación e ID) por separado.

Esto parece similar a su enfoque de "Conjunto de datos compartidos". Sin embargo, no creo que los inconvenientes que enumere sean problemas reales inherentes a este enfoque. Echemos un vistazo a ellos.

Ahora, el problema que tengo con este enfoque es que cuando la lista de usuarios se vuelve enorme (digamos millones), la descarga puede demorar un poco

¡No necesita descargarlos todos! Fusionar todas las entidades descargadas con entities no significa que deba consultarlas todas. Las entities deben contener todas las entidades que se han descargado hasta ahora, no todas las entidades del mundo. En cambio, solo descargaría los que está mostrando actualmente de acuerdo con la información de paginación.

cuando navego directamente a / detail /, todavía no habría descargado a todos mis usuarios, por lo que para obtener datos solo para uno, tendré que descargarlos todos. Millones de usuarios solo para editar uno.

No, pedirías solo uno de ellos. La acción de respuesta se dispararía, y el reductor responsable de las entities fusionaría esta entidad única en el estado existente. El hecho de que state.entities.users pueda contener más de un usuario no significa que deba descargarlos todos. Piense en las entities como en un caché que no tiene que llenarse.

Finalmente, lo dirigiré nuevamente al ejemplo del "mundo real" del repositorio de Redux. Muestra exactamente cómo escribir un reductor para la información de paginación y la memoria caché de la entidad, y cómo normalizar JSON en sus respuestas API con normalizr para que sea fácil para los reductores extraer información de las acciones del servidor de manera uniforme.