<p>dva 2.0</p>

Wie wäre es mit nativer Unterstützung für ts?

Ziehen Sie beim Demodellieren in Erwägung, die Übergabe eines Reduzierers zu unterstützen, um nicht verwendete Zustandsdaten zu zerstören? https://github.com/dvajs/dva/issues/769

Wie wäre es mit dva-cli umbenannt in roadhog? Damit das Konzept nicht verwechselt wird.

Persönlich stimme ich der nativen Unterstützung für ts nicht zu. Das Framework sollte versuchen, es von anderen, nicht verwandten Technologie-Stacks zu entkoppeln, rein zu halten und lieber weniger zu tun. Zum Beispiel kann das Zustandsproblem des Unmount-Modells auch mit dem gelöst werden vorhandene API und React-Router Geplant ist eine Aufspaltung in unabhängige Komponenten wie zB React-Router-DVA, für rn kann ich auch eine React-Navigation-Dva schreiben.

Es gibt auch Optimierungsschemata, die auch in Form von Plug-Ins unterstützt werden können, wie z. B. dva.use(reselect) , genau wie beim Express-Middleware-Mechanismus sind nur statische Plug-Ins integriert und die anderen werden separat unterstützt , und sogar Saga können verfügbar sein

@nihgwu Ich

Ich bin mit der Plug-in-Lösung einverstanden, ist dies möglich:

view - dva-core - [插件]

Unter ihnen ist der Teil, der dem aktuellen dva entspricht:

• dva-core
• dva-saga
• Router

Die letzten beiden sind Plugins.

Kann dva als Bibliothek positioniert werden, die sich darauf konzentriert, die Beziehung zwischen Ansichten und Daten auszudrücken? Was für ein Framework ist die Ansicht und welche Methode ist die Datenquelle, alles austauschbar gemacht? Um ein reibungsloses Upgrade auf 1.0 zu ermöglichen, definieren Sie dann dva als die Standardkombination von dva-core und saga?

Ich weiß nicht, ob die zugrunde liegende Kapselung geeignet ist, den Dispatch-Typ des Instance-Typs zu unterstützen?

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

Das Auswendiglernen von Strings ist ebenfalls mühsam und vergessen oft, einen Namensraum zu schreiben. Wenn es eine Dropdown-Eingabeaufforderung gibt, ist es auch bequem, sie zu rekonstruieren~

Ich weiß nicht, ob es möglich ist, standardmäßig eine Reihe von Reduzierern für alle Daten im Bundesstaat bereitzustellen
In den meisten Szenarien muss ich manuell einen Reduzierer schreiben, der einem Feld möglicherweise nur einen Wert zuweisen kann. Wenn ich also standardmäßig eine vorgefertigte Einzelfeldsatzmethode für mich bereitstellen kann, wäre dies ziemlich gut.

Können Reducer als Baum implementiert werden?Wie jetzt ist ns split gezwungen, die Logik abzuflachen.Ein Modell entspricht der Wurzel eines Reducers, und es hängen zu viele Reducer darunter.

@xufei Ich denke, Saga sollte im Kern sein, und es ist nicht die aktuelle

@xufei Es tut mir leid, ich hatte auch das Gefühl, dass Sie sich auf das Schreiben in ts beziehen sollten, aber ich denke nicht, dass die Benutzeroberfläche von dva auch einfach ist und aufgrund von ts nicht umgeschrieben werden kann Typ-Dateien.

@sorrycc saga

Kann Immutable.js unterstützt werden?

Unterstützt Immutable.js, Immutable.js spielt eine herausragende Rolle bei der Leistungsoptimierung

Roadhog-Packaging ist zu leistungsaufwändig. Versuchen Sie, es zu optimieren. Wenn Sie können, optimieren Sie es so weit wie möglich. Jetzt müssen Sie andere Container stoppen, bevor der Server das Projekt erstellt, sonst bleibt der Server hängen.

Immutable.js ist veraltet. Auch die Kombination von Lodash- und Spread-Vorgängen kann unveränderliche Effekte erzielen. Und Lodash ist im Grunde eingebaut.

Tatsächlich ist die Entwicklungserfahrung von dva 1.x bereits sehr gut, ähnlich wie bei der Unterstützung von Immutable.js, Split Saga, nativer Unterstützung von ts, es fühlt sich unnötig an, alles gehört zur Selbstliebe des Entwicklers, und es ist nicht viel auf die tatsächliche Entwicklungseffizienz und Erfahrung Einfluss.

Persönlich sind bei dva 2.x 4 Punkte zu beachten:

1. Die Optimierung der Serviceschicht, ob sie in das Modell extrahiert und in einer einheitlichen Weise verpackt werden kann, kümmert sich im Grunde nicht um request , und bietet dann standardmäßig die Behandlung von Netzwerkausnahmen, und jetzt im Grunde brauchen Sie um request.js selbst zu schreiben;

2. Es stellt das Problem des Effekt-Callbacks der View-Schicht dar. Es ist unrealistisch (zu umständlich), die Geschäftslogik komplett in Modelldaten zu zerlegen und im Effekt zu verarbeiten, so dass in diesem Bereich eine elegantere Lösung benötigt wird.

3. Es ist der Bau der umliegenden Gemeinden von dva. Derzeit sind die Arten von Gerüsten reich an Beispielen, aber es besteht weiterer Baubedarf. Es scheint, als ob das Ziel darin besteht, das Ressourcenniveau der Winkel- oder Reaktionsgemeinde selbst zu erreichen.

4. Die Verbesserung der Build-Tools, Leistung, Funktionen usw. (derzeit Mock) ist noch etwas mühsam

Was mich am meisten beunruhigt, ist die Trennung von router .Ich denke, dva nur redux + redux-saga . redux Community plädiert dafür, so wenig wie möglich zu tun, daher fühlen sich die 1.x-Pakete react-router und fetch unnötig an, ebenso wie die oben erwähnten Immutable . Das gehört zur Vorliebe des Entwicklers. Als Betreuer sollte man nicht geneigt sein. Für die Vorliebe des Entwicklers kann es in Form von Plug-Ins unterstützt werden. Hinzu kommt das Problem der Serviceschicht. Bei Bedarf , Sie können plugin selbst schreiben. Es sollte nicht in dva-core

@nihgwu Was ist der Zweck des Extrahierens von Routern?

@nikogu hat zu viel getan, und Anfänger werden ratlos sein, wissen nicht, was das Prinzip ist.Aber wenn das Dokument detailliert ist, ist es auch möglich

Was ist der Zweck des Entfernens des Routers?

@nikogu

Derzeit ist der Anwendungsbereich von dva etwas eng, und es ist stark an die React-Community gebunden, natürlich einschließlich View, und auch stark an React-Router. Aber nachdem ich es verwendet hatte, stellte ich fest, dass einige Orte keinen Router benötigen, wie beispielsweise drahtlose mehrseitige Anwendungen; an einigen Orten ist Reak-Router nicht anwendbar, wie beispielsweise Reaktiv-Native; an einigen Orten muss kein Reagieren erforderlich sein, wie beispielsweise node , Elektron und Applets.

Ich denke, dva kann mehr.

@nikogu zieht sich vom Router zurück, weil wir verschiedene Router haben

Ich verstehe, dass dva Redux- und Saga-Code und -Logik in einer neuen Form organisiert, anstatt einen vollständigen Satz von Webentwicklungs-Frameworks wie Express bereitzustellen, das auch die vorhandene API von Node verwendet, um die grundlegenden Funktionen des Webservers bereitzustellen Beschäftigen Sie sich mit Body, Cookie und welche Template-Engine Sie wählen, kann über Middleware angepasst werden

Wenn Sie eine Komplettlösung mögen, können Sie ein dva-ant = dva-core + dva-plugins Ihren eigenen Gebrauch implementieren

Die Kombination von dva sollte die Kombination von Redux und Saga sein, denn diese beiden sind der Kern des Datenzustandsflusses, und die anderen können nur als auf Daten basierende Peripherie betrachtet und durch Plug-Ins oder andere Methoden unterstützt werden. Wir können Express und Django vergleichen, der typische Unterschied zwischen weniger tun und mehr tun, manche Leute mögen groß und vollständig, aber die js-Community respektiert klein aber fein

Was die direkte Verwendung von Redux betrifft, so verwende ich dva hauptsächlich, weil dva die Codestruktur und Logik von Redux vereinfachen und die Produktionseffizienz verbessern kann.Dies ist auch der Kern von dva, das auf Redux basiert.

Wenn wir blindlings mehr tun, werden die Anwendungsszenarien von dva immer enger: React-Router kann zum Beispiel nicht in RN verwendet werden (v4 unterstützt bereits, ist aber sehr einfach), RN kommt auch mit Fetch und es gibt andere starke Bindungen . Die Bibliothek wird auch Upgrade-Abhängigkeitsprobleme verursachen. Es ist immer noch React-Router. V4 unterstützt RN, aber dva ist immer noch V2. Wir müssen warten, bis dva den React-Router aktualisiert hat, bevor es verwendet werden kann. Wenn es ein Plug- in und aktualisieren Sie unabhängig, es wird kein solches Problem geben

Was ich oben mit dva-core meine, ist, den kleinen Kern als dva-core zu behandeln, Router und dergleichen darin zu verwenden und dann einige Standardintegrationsschemata zu entwickeln, wie die firmeninterne vereinheitlichte Version für das Middle- und Backoffice , und für H5, für kleine Programme, serverseitiges Rendering usw.

2:00:
1. In der eigentlichen Entwicklung ist die Geschäftslogik im Modell implementiert und die Datei zu groß Welche Beziehung besteht zwischen dem Anderen und dem Service? Service oder Anfrage kann eingebaut werden
2. Ändern Sie den React-Router auf das systemeigene Plug-In oder was auch immer, der Zweck besteht darin, die Abhängigkeit zu befreien

Wann startet 2.0?

Die steckbare ssr-Lösung abstrahiert die Verwaltung des Routers. Die Serverseite kann die erste Routing-Anfrage übernehmen und die gemeinsame dva () verwenden, um den Zustandsbaum zu initialisieren. Es fühlt sich an, dass das Server-Rendering während der Aktualisierung der dva schwach wird die Anwendung neuer Funktionen.

TypeScript und RN.Hoffe auf bessere Unterstützung

Denken Sie an einen anderen, geben Sie einen Standardwert für namespace

Bei der Verwendung von dva wird es immer Fälle geben, in denen reducer kein Präfix erfordert und die aktuelle Implementierung von dva namespace bereitstellen muss, also habe ich einen Vorschlag, wenn namespace ist default (oder global , * ), wir denken, dass model unter reducers ohne Präfix ist

Denken Sie persönlich an ein paar Punkte:

• Hängt nicht von redux-saga , sodass Sie ganz einfach einige Funktionen hinzufügen können (z. B. Async/Await-Unterstützung).
• Aufteilung in mehrere kleine Module (z. B. ein einzelner Store, ein einzelner Router)
• Verschachteltes Modell unterstützen

Wir haben kürzlich vuex basierend auf redux modelliert https://github.com/d-band/yax

Es wird empfohlen, den Server serverseitig zu rendern und Front- und Backend zusammen zu schreiben!

Kann ich den Namen des Routenverzeichnisses festlegen? Verwenden Sie zum Beispiel Container
Eigentlich möchte ich den Katalog nach Funktion unterteilen, Modell, Service und Container zusammenstellen, sonst zerstört der Sprung zu mehreren Katalogen den Herzfluss. Um zu wissen, was die user.js im Tab über dem Sublime geöffnet hat, habe ich sie bereits so benannt: user.jsx, user.model.js, user.service.js. Zusammenstellen von user/model.js, service.js, container.js

Verzeichnisorganisationen wie @zheeeng werden jetzt unterstützt und dva hat keine Einschränkungen bei der Verzeichnisorganisation.

@xufei
@sorrycc

Ziehen Sie beim Demodellieren in Erwägung, die Übergabe eines Reduzierers zu unterstützen, um nicht verwendete Zustandsdaten zu zerstören?

Die manuelle Steuerung ist zu mühsam, es wird empfohlen, direkt einen Satz GC zu implementieren

Bitte aktualisieren Sie pathToRegexp, seine Analyse- und Kompiliermethoden können nicht direkt verwendet werden

Vereinbarung ist besser als Konfiguration, da die Kopplung mit anderen Projekten oder Technologie-Stacks reduziert wird.

Das Effektgeschäft ist zu schwer, und die Idee von Model-Extend ist ganz gut

@nihgwu stimmt persönlich zu, dass „der Kern von

@sorrycc Hat

Ich hoffe stark, dass dva-cli wählen kann, TypeScript-Boilerplate zu generieren

dva-core kann bereits in WeChat-Applets verwendet werden

@yautah probiert? Sie können den Plan teilen, nachdem Sie ihn ausprobiert haben.

Ich glaube, dass dva-core nur die Redux-Datenstrom-Neukapselung bereitstellen muss, ob die anderen in Form von Plug-Ins bereitgestellt werden können oder es besser wäre, dass Benutzer sie auswählen, z. B. Paket- und Routing-Schemata.

Ich hoffe, dva-cli zu unterstützen, um den Stift zu unterstützen

SSR nicht unterstützen.

Wie man HRM konfiguriert, API-Schreiben ist relativ wenige