Dva: ¿Cómo implementar la anidación de modelos (modularización)?

El negocio es así
Por ejemplo, hay 5 productos relativamente independientes en la aplicación y cada producto tiene un modelo relativamente independiente.

En este caso, solo una sola capa de modelo estará muy apretada

Por supuesto, también se puede distinguir en el espacio de nombres, pero actualmente el espacio de nombres se usará directamente como el nombre del estado (no se pueden usar símbolos especiales como . )

Solo una sola capa de modelo será muy apretada

No entendí

@coder

Al mirar el documento, el modelo tiene solo una capa físicamente. Si hay una gran cantidad de modelos, es probable que haya un conflicto de espacio de nombres con el mismo nombre (especialmente para proyectos grandes, algunos modelos tienen la misma semántica). esta vez, es posible que tengan que estar en el espacio de nombres. Agregue un prefijo de manera predominante como una distinción entre los módulos.

Entonces, me gustaría preguntar si hay un mejor esquema de anidación o modularización de modelos.

No se recomienda anidar demasiado profundo en el estado. Si aún anida el modelo, será más complicado. Se siente que hay un problema con el diseño.
No entiendo la pregunta, ¿puede darme una demostración sencilla?

Esta pregunta se entiende a grandes rasgos. Ayer la discutimos. Se trata principalmente del significado del modelo. Hay dos tendencias: seguir la mirada y seguir la entidad empresarial.

Desde el punto de vista del diseño actual, debería ser más apropiado seguir la vista, porque el estado de cada modelo es aislado y todo en el modelo sigue su propio estado. Desde esta perspectiva, es mejor seguir la vista. Esto En este caso, el significado de modelo es modelo de vista.

Pero de esta manera, esas adiciones comerciales, eliminaciones, efectos de verificación y modificación utilizados por el modelo pueden existir en todos los modelos utilizados, por ejemplo:

Hay vistas ABC, entidades comerciales XYZ, donde:

A usa CRUD de XY
B usa CRUD de YZ
C usa CRUD de XZ

Nuestro modelo está diseñado para seguir la vista ABC, y debe haber algunos efectos de redundancia en él. Por ejemplo, Y existe en AB al mismo tiempo, y puede haber redundancia en el código. Desde otro punto de vista, el uso de Y en AB en sí no debería considerar la reutilización, y el proceso de llamada a reutilizar debería situarse en el siguiente nivel, es decir, el servicio.

Así, la estructura organizativa se convierte en:

  a
  b
  c
service
  x
  y
  z

Y la estructura de modelA:

{
  effects: {
    *x() {
      yield call(serviceX);
    },
    *y() {
      yield call(serviceY);
    }
  }
}

La estructura de modelB:

{
  effects: {
    *y() {
      yield call(serviceY);
    },
    *z() {
      yield call(serviceZ);
    }
  }
}

Más adelante, escribiré una demostración más orientada a los negocios y daré algunas sugerencias para el uso de escenarios.

¡@xufei necesita orientación como el tío

@xufei ¿Puedes aprender de tu demostración?Estoy preocupado por esto recientemente

¿La demo de

¿La demo de

Creo que es más razonable tener un modelo de negocio y un modelo de vista. Por ejemplo, el usuario actual puede tener un modelo de usuario para el procesamiento global.
Si otros componentes involucran información de usuario actual, simplemente conéctese directamente al modelo de usuario.Depende de las necesidades del negocio.

@ liSong5713 Se hizo clic en la lista de usuarios en la lista de detalles del usuario, se hizo clic en los detalles del usuario en la administración de claves si estos deben colocarse en el mismo modelo de usuario

@lwbGH Esto depende de las responsabilidades de su modelo. El modelo de usuario puede ser la información básica y de uso común del usuario actualmente conectado. Si desea cambiar la información detallada del usuario, como el registro de la operación del usuario, esta información puede ser completamente diferente del modelo. Creo que la división del modelo radica en un poco:
El grado de compartición del estado de los componentes del nivel , si una página simple corresponde a un modelo a nivel de página, será complicado

Por supuesto, también se puede distinguir en el espacio de nombres, pero actualmente el espacio de nombres se usará directamente como el nombre del estado (no se pueden usar símbolos especiales como . )
. No se puede usar como clave, puede usar _. Actualmente, estamos restringidos en el espacio de nombres. Los modelos se pueden dividir en módulos por vista y negocio, pero el espacio de nombres está restringido por "nombre_de_archivo_carpeta".