In der Firma, für die ich arbeite, entwickeln wir eine große Anwendung mit mehreren Formen, die der Benutzer ausfüllen muss, um sich für unser Programm anzumelden. Wenn alle Fragen beantwortet sind, erreicht der Benutzer einen Abschnitt, der alle seine Antworten zusammenfasst, ungültige Antworten hervorhebt und dem Benutzer die Möglichkeit gibt, einen der vorhergehenden Formularschritte erneut zu bearbeiten und seine Antworten zu überarbeiten. Diese Logik wird für eine Reihe von Abschnitten der obersten Ebene wiederholt, die jeweils mehrere Schritte / Seiten und eine Übersichtsseite enthalten.
Um dies zu erreichen, haben wir eine Komponente für jeden einzelnen Formularschritt erstellt (sie sind Kategorien wie "Persönliche Details" oder "Qualifikationen" usw.) zusammen mit ihren jeweiligen Routen und einer Komponente für die Zusammenfassungsseite.
Um es möglichst trocken zu halten, haben wir mit der Erstellung eines "Master" -Dienstes begonnen, der die Informationen für alle verschiedenen Formularschritte (Werte, Gültigkeit usw.) enthält.
%Vor%Dieser Dienst wird von allen Komponenten verwendet, um die HTML-Formularbindungen für jede Komponente einzurichten, indem auf den entsprechenden Objektschlüssel zugegriffen wird und verschachtelte Formulargruppen erstellt werden, sowie auf der Seite Zusammenfassung, deren Darstellungsebene nur 1-fach ist gebunden (Modell - & gt; Ansicht).
%Vor%Danach haben wir begonnen, die folgende Syntax in den Komponenten zu verwenden, um die Formularsteuerelemente zu erreichen, die im Hauptformulardienst angegeben sind:
%Vor%das scheint in unseren unerfahrenen Augen wie ein Code-Geruch zu sein. Wir haben große Bedenken, wie sich eine solche Anwendung skalieren lässt, wenn man bedenkt, wie viele Abschnitte wir am Ende haben werden.
Wir haben verschiedene Lösungen diskutiert, aber wir können uns keine vorstellen, die die Formular-Engine von Angular nutzt, uns erlaubt, unsere Validierungshierarchie intakt zu halten und ist auch einfach.
Gibt es einen besseren Weg, um das zu erreichen, was wir zu erreichen versuchen?
Ich habe an anderer Stelle von @ngrx/store kommentiert, und obwohl ich es immer noch empfehle, glaube ich, dass ich dein Problem leicht missverstanden habe.
Wie auch immer, Ihr FormsControlService ist im Grunde ein globaler const. Im Ernst, ersetzen Sie die export class FormControlService ... durch
und welchen Unterschied macht es? Anstatt einen Service zu erhalten, importieren Sie einfach das Objekt. Und da wir es jetzt als typisierten const global betrachten, können wir die Schnittstellen definieren, die wir verwenden ...
%Vor%und seit wir das getan haben, können wir die Definitionen der einzelnen Formulargruppen aus dem einzelnen monolithischen Modul heraus verschieben und die Formulargruppe definieren, in der wir das Modell definieren. Viel sauberer.
%Vor%Aber jetzt haben wir all diese Definitionen für einzelne Formulargruppen in unseren Modulen verstreut und es gibt keine Möglichkeit, sie alle zu sammeln :( Wir brauchen eine Möglichkeit, alle die Formulargruppen in unserer Anwendung zu kennen.
>Aber wir wissen nicht, wie viele Module wir in Zukunft haben werden, und wir möchten sie vielleicht lazy laden, damit ihre Modellgruppen möglicherweise nicht beim Start der Anwendung registriert werden.
Umkehrung der Kontrolle zur Rettung! Machen wir einen Service mit einer einzigen injizierten Abhängigkeit - einem Multi-Provider, der mit all unseren verstreuten Formulargruppen injiziert werden kann, wenn wir sie in unseren Modulen verteilen.
%Vor%Erstellen Sie dann irgendwo ein Manifest-Modul (das in das App-Modul "core" eingefügt wird) und bauen Sie Ihren FormService
auf %Vor%Wir haben jetzt eine Lösung, die lautet:
Ich habe eine ähnliche Anwendung gemacht. Das Problem ist, dass Sie alle Ihre Eingaben gleichzeitig erstellen, was wahrscheinlich nicht skalierbar ist.
In meinem Fall habe ich einen FormManagerService ausgeführt, der ein Array von FormGroup verwaltet. Jeder Schritt verfügt über eine FormGroup, die einmal in der Ausführung für ngOnInit der Schrittkomponente initialisiert wird, indem sie ihre FormGroup-Konfiguration an den FormManagerService sendet. So ähnlich:
%Vor%Sie benötigen eine ID, um zu wissen, welche FormGroup dem Schritt entspricht. Aber danach können Sie die Forms-Konfiguration in jedem Schritt aufteilen (so kleine Konfigurationsdateien, die leichter zu warten sind als eine große Datei). Dadurch wird die anfängliche Ladezeit minimiert, da die FormGroups nur bei Bedarf erstellt werden.
Schließlich müssen Sie vor dem Senden nur Ihr FormGroup-Array zuordnen und prüfen, ob alle gültig sind. Stellen Sie nur sicher, dass alle Schritte besucht wurden (andernfalls wird keine FormGroup erstellt).
Dies ist vielleicht nicht die beste Lösung, aber es passte gut in mein Projekt, da ich den Benutzer dazu zwinge, meinen Schritten zu folgen. Gib mir dein Feedback. :)
Ist es wirklich notwendig, die Formularsteuerelemente im Service zu behalten? Warum nicht den Service als Datenverwalter verlassen und die Formularkontrollen in den Komponenten haben? Sie können den CanDeactivate -Wächter verwenden, um zu verhindern, dass der Benutzer von einer Komponente mit ungültigen Daten weg navigiert.
Tags und Links forms architecture angular