<p>dva 2.0</p>

¿Qué tal el soporte nativo para ts?

Al desmodelar, ¿considera admitir el paso de un reductor para destruir los datos de estado no utilizados? https://github.com/dvajs/dva/issues/769

¿Qué tal dva-cli renombrado a roadhog? Para que no se confunda el concepto.

Personalmente, no estoy de acuerdo con el soporte nativo para ts. El marco debería intentar desvincularlo de otras pilas de tecnología no relacionadas, mantenerlo puro y, en cambio, hacer menos. Por ejemplo, el problema de estado del modelo de desmontaje también se puede hacer con el api existente y react-router El plan es dividirlo en componentes independientes como react-router-dva.También puedo escribir un react-navigation-dva para rn.

También hay esquemas de optimización que también se pueden admitir en forma de complementos, como dva.use(reselect) , al igual que el mecanismo de middleware expreso, solo se incorporan complementos estáticos y los demás se admiten por separado , e incluso la saga puede estar disponible.

@nihgwu Me equivoqué, es decir que, como antd, está escrito en ts y no restringe a los usuarios, esto tiene la ventaja de no tener que sincronizar y publicar manualmente archivos de tipo todo el tiempo.

Estoy de acuerdo con la solución del complemento, ¿es posible hacer esto?

view - dva-core - [插件]

Entre ellos, la parte igual al dva actual es:

• dva-core
• dva-saga
• enrutador

Los dos últimos son complementos.

¿Se puede posicionar dva como una biblioteca que se enfoca en expresar la relación entre vistas y datos? ¿Qué tipo de marco es la vista y qué método es la fuente de datos, todos reemplazables? Luego, para actualizar sin problemas con 1.0, defina dva como la combinación predeterminada de dva-core y saga?

No sé si la encapsulación subyacente es conveniente para admitir el tipo de envío del tipo de instancia.

dispatch({
  type: model => model.product.loadAll,
})

Memorizar cadenas también es problemático y, a menudo, se olvidan de escribir el espacio de nombres; si hay un mensaje desplegable, también es conveniente reconstruir ~

No sé si es posible proporcionar un conjunto de reductores de forma predeterminada para todos los datos en el estado
En la mayoría de los escenarios, necesito escribir manualmente un reductor, que puede simplemente asignar un valor a un campo, por lo que si puedo proporcionarme un método de conjunto de un solo campo listo para usar de forma predeterminada, sería bastante bueno.

¿Se pueden implementar reductores como un árbol? Como ahora, ns split se ve obligado a aplanar la lógica. Un modelo corresponde a la raíz de un reductor, y hay demasiados reductores colgando debajo.

@xufei Creo que la saga debería estar en el núcleo, y no es la sin saga.Parece que es difícil extraer saga en un plug-in desde la perspectiva de la implementación.

@xufei Lo siento, también sentí que deberías

@sorrycc Separando saga También doy un ejemplo, es cierto que el núcleo de dva es redux + redux-saga, pero desde la perspectiva de implementación, podemos separarlo en plug-ins mediante callback hooks.

¿Se puede admitir Immutable.js?

Admite Immutable.js, Immutable.js tiene un papel destacado en la optimización del rendimiento.

El empaquetado de Roadhog consume demasiado rendimiento. Vea si puede optimizarlo. Si puede, optimícelo tanto como sea posible. Ahora debe detener otros contenedores antes de que el servidor compile el proyecto, de lo contrario, el servidor se bloqueará.

Immutable.js está obsoleto. La combinación de operaciones lodash y spread también puede lograr efectos inmutables. Y lodash está básicamente integrado.

De hecho, la experiencia de desarrollo de dva 1.x ya es muy buena, similar a si es compatible con Immutable.js, split saga, soporte nativo ts, se siente innecesario, todos pertenecen al amor propio del desarrollador, y no es mucho a la eficiencia y experiencia del desarrollo actual.

Personalmente, hay 4 puntos que deben ser considerados por dva 2.x:

1. La optimización de la capa de servicio, ya sea que se pueda extraer en el modelo y empaquetar de manera unificada, básicamente no se preocupa por request , y luego proporciona manejo de excepciones de red de forma predeterminada, y ahora básicamente necesitas escribir request.js usted mismo;

2. Es el problema de la devolución de llamada del efecto de la capa de vista. No es realista (demasiado engorroso) separar completamente la lógica empresarial en los datos del modelo y procesarlos en el efecto, por lo que se necesita una solución más elegante en esta área.

3. Es la construcción de las comunidades aledañas a dva. En la actualidad, los tipos de andamios son ricos en ejemplos, pero se necesita más construcción. Parece que el objetivo es alcanzar el nivel de recursos de la comunidad angular o reactiva en sí.

4. La mejora de las herramientas de compilación, el rendimiento, las funciones, etc. (actualmente simuladas) sigue siendo un poco problemática.

Para mí, lo que más me preocupa es la separación de router . Creo que dva solo debe incluir redux + redux-saga . redux comunidad react-router y fetch siente innecesario, así como el Immutable mencionado anteriormente. Esto pertenece a la preferencia del desarrollador. Como mantenedor, no debe inclinarse. Para la preferencia del desarrollador, se puede apoyar en forma de complementos. También existe el problema de la capa de servicio. Si es necesario , puede escribir plugin usted mismo, no debe incluirse en dva-core

@nihgwu ¿Cuál es el propósito de extraer enrutadores?

@nikogu ha hecho demasiado, y los novatos estarán perdidos, no sé cuál es el principio.Pero si se detalla el documento, también es posible

¿Cuál es el propósito de quitar el enrutador?

@nikogu

En la actualidad, el alcance de la aplicación de dva es un poco estrecho y se ha vinculado fuertemente a la comunidad react, naturalmente incluyendo view, y también fuertemente ligado a react-router. Pero después de usarlo, descubrí que algunos lugares no necesitan enrutador, como las aplicaciones inalámbricas de varias páginas; algunos lugares react-router no es aplicable, como react-native; algunos lugares no necesitan reaccionar, como node , electrones y applets.

Creo que dva puede hacer más.

@nikogu se aleja del enrutador porque podemos tener diferentes enrutadores. Por ejemplo, en RN, puedo usar react-navigation, y react-navigation también es compatible con la web, que puede ser totalmente compatible con el complemento para lograr una mejor personalización

Entiendo que dva organiza el código y la lógica de redux y saga en una nueva forma, en lugar de proporcionar un conjunto completo de marcos de desarrollo web, como express, que también utiliza la API existente de node para proporcionar las funciones básicas del servidor web. En cuanto a cómo ¿Se ocupa del cuerpo, las cookies y qué motor de plantilla elige se puede personalizar a través de middleware?

Si le gusta una solución completa, puede implementar un dva-ant = dva-core + dva-plugins su propio uso

La combinación de dva debe ser la combinación de redux y saga, porque estos dos son el núcleo del flujo de estado de datos, y los otros solo pueden considerarse como periféricos basados ​​en datos y pueden ser compatibles con complementos u otros métodos. Podemos comparar Express y Django, la diferencia típica entre hacer menos y hacer más, a algunas personas les gusta lo grande y completo, pero la comunidad js respeta lo pequeño pero hermoso

En cuanto al uso directo de redux, la razón principal por la que uso dva es porque dva puede simplificar la estructura del código y la lógica de redux y mejorar la eficiencia de producción Este es también el núcleo de dva basado en redux.

Si hacemos más a ciegas, los escenarios de aplicación de dva se volverán cada vez más estrechos. Por ejemplo, react-router no se puede usar en RN (v4 ya es compatible, pero es muy básico), RN también viene con fetch y hay otras vinculaciones fuertes . La biblioteca también causará problemas de dependencia de actualización. Todavía es react-router. V4 es compatible con RN, pero dva sigue siendo V2. Tenemos que esperar a que dva actualice react-router antes de que se pueda usar. Si es un plug- en y actualizar de forma independiente, no habrá tal problema. NS

Lo que quiero decir con dva-core anteriormente es tratar el núcleo pequeño como dva-core, tomar enrutadores y similares en esto, y luego desarrollar algunos esquemas de integración predeterminados, como la versión unificada interna de la compañía, para el medio y el back office. , y para H5, para programas pequeños, renderización del lado del servidor, etc.

2:00:
1. En el desarrollo real, la lógica empresarial está implementada en el modelo y el archivo es demasiado grande ¿Cuál es la relación entre el otro y el servicio? El servicio o la solicitud se pueden incorporar
2. Cambie react-router al propio complemento del sistema, o lo que sea, el propósito es liberar la dependencia

¿Cuándo comenzará 2.0?

La solución SSR conectable abstrae la administración del enrutador. El lado del servidor puede hacerse cargo de la primera solicitud de enrutamiento y usar el dva () compartido para inicializar el árbol de estado. Se siente que a medida que el dva continúa actualizándose, la representación del servidor es débil en la aplicación de nuevas funciones.

TypeScript y RN.Espero obtener un mejor apoyo

Piense en otro, proporcione un namespace predeterminado

En el proceso de uso de dva, siempre habrá casos en los que reducer no requiera ningún prefijo, y la implementación actual de dva debe proporcionar namespace , así que tengo una propuesta, si namespace es default (o global , * ), creemos que model debajo de reducers es Sin prefijo

Piense personalmente en algunos puntos:

• No depende de redux-saga , por lo que puede agregar fácilmente algunas funciones (como soporte asíncrono / en espera)
• Dividir en varios módulos pequeños (por ejemplo, una sola tienda, un solo enrutador)
• Soporte modelo anidado

Recientemente modelamos vuex basados ​​en redux escribimos un punto de referencia: https://github.com/d-band/yax

Se recomienda que el servidor se pueda renderizar en el lado del servidor, ¡y que el front-end y el back-end se puedan escribir juntos!

¿Puedo configurar el nombre del directorio de rutas? Por ejemplo, use contenedor
De hecho, quiero dividir el catálogo por función, juntando modelo, servicio y contenedor, de lo contrario, el salto a varios catálogos destruirá el flujo del corazón. Para saber qué abrió el user.js en la pestaña sobre lo sublime, ya lo he nombrado así: user.jsx, user.model.js, user.service.js. Junte user / model.js, service.js, container.js

Las organizaciones de directorios como @zheeeng ahora son compatibles y dva no tiene restricciones sobre la organización de directorios.

@xufei
@ lo siento

Al desmodelar, ¿considera admitir el paso de un reductor para destruir los datos de estado no utilizados?

El control manual es demasiado problemático, se recomienda implementar directamente un conjunto de GC

Actualice pathToRegexp, sus métodos de análisis y compilación no se pueden usar directamente

El acuerdo es mejor que la configuración, lo que reduce el acoplamiento con otros proyectos o pilas de tecnología.

El negocio de los efectos es demasiado pesado y la idea de extender el modelo es bastante buena.

@nihgwu está de acuerdo personalmente en que "el núcleo de

@sorrycc ¿Tiene

Espero encarecidamente que dva-cli pueda optar por generar una plantilla de TypeScript

dva-core ya se puede usar en los applets de WeChat

@yautah lo probó? Puede compartir el plan después de haberlo probado.

Siento que dva-core solo necesita proporcionar reencapsulación de flujo de datos redux, ya sea que los otros se puedan proporcionar en forma de complementos, o sería mejor que los usuarios los elijan, como esquemas de empaquetado y enrutamiento.

Espero admitir dva-cli para admitir stylus

Soporte ssr no.

Cómo configurar HRM, la escritura de API es relativamente poca