0
234
Views¿Cómo pensar en la estructura del modelo/estado al usar ComposableArchitecture?
Estoy tratando de crear una aplicación de seguimiento de tiempo básica usando SwiftUI y ComposableArchitecture. Pero estoy luchando con la forma en que debería pensar en modelar la estructura de datos/estado de la aplicación de forma modular. La aplicación es una aplicación de seguimiento del tiempo, por lo que tiene: un Project , que puede tener cero o más Task , que puede tener cero o más entradas de Activity .
A continuación se muestra un diagrama de mi estructura actual.
El problema que me sale es que con esta estructura ahora ProjectState tiene dos listas de tareas diferentes. Uno a través de project.tasks y otro a través de tasks: IdentifiedArrayOf<TaskState> .
¿Cómo debo pensar en modelar esto?
No quiero fusionar el modelo de datos y el estado de la aplicación, ya que los estados de la aplicación son más específicos de la vista y pueden agregar un estado específico de la vista, que puede diferir en diferentes lugares. El modelo de datos es el modelo general que se utilizará en toda la aplicación. Es por eso que podría ser bueno tener una relación entre Project->Task->Activity . Pero el estado de la aplicación de arquitectura componible también necesita una relación similar entre sus diferentes estados.
1 answers
Answer question0
Bien, después de ver muchos de los proyectos de ejemplo de PointFree , creo que podría haber tenido un modelo de metal incorrecto al mirar esto. Creo que me equivoqué al ver el modelo de datos y el estado de la aplicación como dos cosas diferentes, y estaba buscando una forma de sincronizarlos.
Al final acepté que son lo mismo y moví todo directamente a AppState . Esto hizo que todo fuera mucho más fácil de razonar, y pude eliminar una gran cantidad de código adicional, lo que podría ser una pista de que este era un buen camino a seguir.
Pero aún me encantaría recibir algunos comentarios si alguien tiene más información con respecto a esto. A continuación se muestra mi estructura actual.
