<p>dva 2.0</p>

Qu'en est-il de la prise en charge native de ts ?

Lors de la démodélisation, envisagez-vous de prendre en charge le passage d'un réducteur pour détruire les données d'état inutilisées ? https://github.com/dvajs/dva/issues/769

Que diriez-vous d'un dva-cli renommé en roadhog ? De peur que le concept ne soit confus.

Personnellement, je ne suis pas d'accord avec la prise en charge native de ts. Le framework devrait essayer de le dissocier des autres piles technologiques sans rapport, le garder pur et en faire moins. Par exemple, le problème d'état du modèle de démontage peut également être résolu avec le api existant et react-router Le plan est de diviser en composants indépendants tels que react-router-dva.Je peux également écrire un react-navigation-dva pour rn.

Il existe également des schémas d'optimisation qui peuvent également être pris en charge sous la forme de plug-ins, tels que dva.use(reselect) , tout comme le mécanisme middleware express, seuls les plug-ins statiques sont intégrés et les autres sont pris en charge séparément , et même la saga peut être disponible.

@nihgwu Je

Je suis d'accord avec la solution du plug-in, est-il possible de faire ceci:

view - dva-core - [插件]

Parmi eux, la partie égale à la dva actuelle est :

• dva-core
• dva-saga
• routeur

Les deux derniers sont des plugins.

Dva peut-il se positionner comme une bibliothèque qui se concentre sur l'expression de la relation entre les vues et les données ? Quel type de cadre est la vue et quelle méthode est la source de données, tous rendus remplaçables ? Ensuite, afin de passer en douceur à la version 1.0, définissez dva comme combinaison par défaut de dva-core et de saga ?

Je ne sais pas si l'encapsulation sous-jacente est pratique pour prendre en charge le type de répartition du type d'instance ?

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

La mémorisation de la chaîne est également gênante et oublie souvent d'écrire l'espace de noms, s'il y a une invite déroulante, il est également pratique de reconstruire ~

Je ne sais pas s'il est possible de fournir un jeu de réducteurs par défaut pour toutes les données de l'état
Dans la plupart des scénarios, je dois écrire manuellement un réducteur, qui peut simplement attribuer une valeur à un champ, donc si je peux me fournir une méthode de définition de champ unique prête à l'emploi par défaut, ce serait plutôt bien.

Les réducteurs peuvent-ils être implémentés sous forme d'arbre ? Comme maintenant, ns split est obligé d'aplatir la logique. Un modèle correspond à la racine d'un réducteur, et il y a trop de réducteurs suspendus en dessous.

@xufei Je pense que la saga devrait être dans le noyau, et ce n'est pas le sans saga. Il semble qu'il soit difficile d'extraire la saga dans un plug-in du point de vue de la mise en œuvre.

@xufei Je suis désolé, j'ai également pensé que vous devriez faire référence à l'écriture en ts, mais je ne pense pas que ce soit nécessaire. Après tout, l'interface de dva est également simple et ne peut pas être réécrite avec ts à cause de tapez des fichiers.

@sorrycc Séparer la saga Je donne aussi un

Immutable.js peut-il être pris en charge ?

Support Immutable.js, Immutable.js a un rôle de premier plan dans l'optimisation des performances

L'empaquetage Roadhog consomme trop de performances. Voyez si vous pouvez l'optimiser. Si vous le pouvez, optimisez-le autant que possible. Maintenant, vous devez arrêter les autres conteneurs avant que le serveur ne construise le projet, sinon le serveur sera bloqué.

Immutable.js est obsolète. La combinaison d'opérations de lodash et de propagation peut également obtenir des effets immuables. Et lodash est fondamentalement intégré.

En fait, l'expérience de développement de dva 1.x est déjà très bonne, similaire à la prise en charge d'Immutable.js, de la saga divisée, du support natif ts, cela semble inutile, tout appartient à l'amour-propre du développeur, et ce n'est pas beaucoup à l'efficacité et à l'expérience de développement réelles.

Personnellement, il y a 4 points qui doivent être pris en compte par dva 2.x :

1. L'optimisation de la couche de service, qu'elle puisse être extraite dans le modèle et conditionnée de manière unifiée, ne se soucie fondamentalement pas de request , puis fournit la gestion des exceptions réseau par défaut, et maintenant vous avez essentiellement besoin écrire request.js vous-même ;

2. C'est le problème du rappel d'effet de la couche de vue.Il est irréaliste (trop lourd) de séparer complètement la logique métier en données de modèle et de la traiter dans l'effet, une solution plus élégante est donc nécessaire dans ce domaine.

3. C'est la construction des communautés environnantes de dva. À l'heure actuelle, les types d'échafaudage sont riches en exemples, mais plus de construction est nécessaire. Il semble que le but soit d'atteindre le niveau de ressource de la communauté angulaire ou de réagir elle-même.

4. L'amélioration des outils de construction, des performances, des fonctions, etc. (actuellement fictives) est toujours un peu gênante

Pour moi, ce qui me préoccupe le plus, c'est la séparation de router . Je pense que dva n'a besoin d'inclure que redux + redux-saga . redux communauté react-router et fetch semblent inutiles, ainsi que les Immutable mentionnés ci-dessus. Cela appartient à la préférence du développeur. En tant que mainteneur, il ne devrait pas être incliné. Pour la préférence du développeur, il peut être pris en charge sous la forme de plug-ins. Il y a aussi le problème de la couche de service. Si nécessaire , vous pouvez écrire plugin vous-même, il ne doit pas être inclus dans dva-core

@nihgwu Quel est le but de l'extraction des routeurs ?

@nikogu en a trop fait, et les novices seront perdus, ne savent pas quel est le principe.Mais si la doc est détaillée, c'est aussi possible

Quel est le but de retirer le routeur

@nikogu

À l'heure actuelle, le champ d'application de dva est un peu étroit et il est fortement lié à la communauté React, y compris naturellement View, et également fortement lié à React-Router. Mais après l'avoir utilisé, j'ai découvert que certains endroits n'avaient pas besoin de routeur, comme les applications multi-pages sans fil ; certains endroits, le routeur réactif n'est pas applicable, comme réactif-natif ; certains endroits n'ont pas besoin de réagir, comme le nœud , électron et applets.

Je pense que dva peut faire plus.

@nikogu s'éloigne du routeur car nous pouvons avoir différents routeurs. Par exemple, dans RN, je peux utiliser la navigation réactive, et la navigation réactive prend également en charge le Web, qui peut être entièrement pris en charge par le plugin pour obtenir une meilleure personnalisation

Je comprends que dva organise le code et la logique redux et saga sous une nouvelle forme, plutôt que de fournir un ensemble complet de cadres de développement Web, tels qu'express, qui utilise également l'API existante du nœud pour fournir les fonctions de base du serveur Web. gérez-vous le corps, le cookie et le moteur de modèle que vous choisissez peut être personnalisé via un middleware

Si vous aimez une solution complète, vous pouvez implémenter un dva-ant = dva-core + dva-plugins votre propre usage

La combinaison de dva devrait être la combinaison de redux et de saga, car ces deux éléments sont au cœur du flux d'état des données, et les autres ne peuvent être considérés que comme des périphériques construits sur des données et peuvent être pris en charge par des plug-ins ou d'autres méthodes. On peut comparer Express et Django, la différence typique entre faire moins et faire plus, certaines personnes aiment grand et complet, mais la communauté js respecte petit mais beau

En ce qui concerne l'utilisation directe de redux, la principale raison pour laquelle j'utilise dva est que dva peut simplifier la structure du code et la logique de redux et améliorer l'efficacité de la production.C'est également le cœur de dva basé sur redux.

Si nous en faisons plus aveuglément, les scénarios d'application de dva deviendront de plus en plus étroits.Par exemple, react-router ne peut pas être utilisé dans RN (v4 prend déjà en charge mais est très basique), RN est également livré avec fetch, et il existe d'autres liaisons fortes . La bibliothèque causera également des problèmes de dépendance de mise à niveau. Il s'agit toujours de react-router. V4 prend en charge RN, mais dva est toujours V2. Nous devons attendre que dva mette à niveau React-Router avant de pouvoir l'utiliser. S'il s'agit d'un plug- et mise à niveau indépendamment, il n'y aura pas de problème de ce genre.

Ce que j'entends par dva-core ci-dessus, c'est traiter le petit noyau comme dva-core, prendre des routeurs, etc., puis développer quelques schémas d'intégration par défaut, tels que la version unifiée interne de l'entreprise, pour le middle et le back office , et pour H5, pour les petits programmes, le rendu côté serveur, etc.

2:00 :
1. Dans le développement réel, la logique métier est implémentée dans le modèle et le fichier est trop volumineux. Quelle est la relation entre l'autre et le service ? Le service ou la demande peut être intégré
2. Remplacez le react-router par le propre plug-in du système, ou autre, le but est de libérer la dépendance

Quand la 2.0 commencera-t-elle ?

La solution ssr enfichable fait abstraction de la gestion du routeur. Le côté serveur peut prendre en charge la première requête de routage et utiliser le dva () partagé pour initialiser l'arbre d'état. l'application de nouvelles fonctionnalités.

TypeScript et RN.J'espère avoir un meilleur support

Pensez à un autre, fournissez un namespace par défaut

Dans le processus d'utilisation de dva, il y aura toujours des cas où reducer ne nécessite aucun préfixe, et l'implémentation actuelle de dva doit fournir namespace , donc j'ai une proposition, si namespace est default (ou global , * ), nous pensons que model sous reducers est Sans préfixe

Pensez personnellement à quelques points :

• Ne dépend pas de redux-saga , vous pouvez donc facilement ajouter certaines fonctionnalités (telles que le support async/wait)
• Divisé en plusieurs petits modules (par exemple, un seul magasin, un seul routeur)
• Prise en charge du modèle imbriqué

Nous avons récemment modélisé vuex basé sur redux écrit un point de référence : https://github.com/d-band/yax

Il est recommandé que le serveur puisse être rendu côté serveur et que les extrémités avant et arrière puissent être écrites ensemble !

Puis-je définir le nom du répertoire des routes ? Par exemple, utilisez le conteneur
En fait, je veux diviser le catalogue par fonction, en mettant ensemble modèle, service et conteneur, sinon le passage à plusieurs catalogues détruira le flux du cœur. Afin de savoir ce qu'est le user.js ouvert dans l'onglet au dessus du sublime, je l'ai déjà nommé ainsi : user.jsx, user.model.js, user.service.js. Rassembler user/model.js, service.js, container.js

Les organisations d'annuaire comme @zheeeng sont désormais prises en charge et dva n'a aucune restriction sur l'organisation d'annuaire.

@xufei
@désolé

Lors de la démodélisation, envisagez-vous de prendre en charge le passage d'un réducteur pour détruire les données d'état inutilisées ?

Le contrôle manuel est trop gênant, il est recommandé de mettre directement en œuvre un ensemble de GC

Veuillez mettre à niveau pathToRegexp, ses méthodes d'analyse et de compilation ne peuvent pas être utilisées directement

L'accord est meilleur que la configuration, ce qui réduit le couplage avec d'autres projets ou piles technologiques.

Le business des effets est trop lourd, et l'idée de model-extend est plutôt bonne

@nihgwu convient personnellement que "le noyau de

@sorrycc Est- dva 2.0 a le dernier plan de version ?

J'espère vivement que dva-cli pourra choisir de générer un passe-partout TypeScript

dva-core peut déjà être utilisé dans les applets WeChat

@yautah a essayé? Vous pouvez partager le plan après l'avoir essayé.

Je pense que dva-core n'a besoin que de fournir une réencapsulation de flux de données redux, que les autres puissent être fournis sous forme de plug-ins, ou qu'il soit préférable que les utilisateurs les choisissent, tels que des schémas d'emballage et de routage.

J'espère prendre en charge dva-cli pour prendre en charge le stylet

Support ssr pas.

Comment configurer HRM, l'écriture d'API est relativement peu