Django: Implementieren eines verschachtelten, wiederverwendbaren Komponentendesigns

Question

Ich arbeite an einer großen Social-Networking-App in Django, wo ich bestimmte Front-End-Komponenten oft verwenden werde und oft mit Funktionen, die so konzipiert sind, dass benutzerdefinierte Komponenten enthalten andere benutzerdefinierte Komponenten, die möglicherweise noch kleinere Unterkomponenten enthalten (ad infinitum). Alle diese Komponenten werden typischerweise dynamisch generiert. Ich versuche herauszufinden, wie ich dies im Django-Framework am besten gestalten kann, so dass meine Komponenten einfach zu warten sind und über klare Programmierschnittstellen verfügen. Sich stark auf den globalen Kontext zu verlassen, scheint das Gegenteil zu sein, aber ich sehe Vorteile darin, redundante Abfragen zu vermeiden, indem sie alle gleichzeitig in der Ansicht ausführen.

Benutzerdefinierte Einführungsschablonen-Tags scheinen eine gute Lösung für die Implementierung von Komponenten zu sein, aber ich frage mich, ob hoch verschachtelte Vorlagen-Tags Leistungsprobleme verursachen können, oder verhindert die Parsing-Architektur dies? Was ist der beste Weg, um auf der Ansichtsebene selbst zu dokumentieren, welcher Kontext benötigt wird, um die Hauptseitenvorlage, benutzerdefinierte Tags und alle zu rendern? Ich stelle mir vor, dass es ein kleiner Albtraum ist, zu versuchen, den Code ordnungsgemäß zu pflegen, um den Vorlagenkontext einzurichten. Zuletzt, was ist der beste Weg, um das CSS für diese Komponenten zu erhalten?

Fühlen Sie sich frei, andere empfohlene Ansätze zum Erstellen eines geschachtelten Komponentenentwurfs vorzuschlagen.

Answer 1

Es ist ein interessantes Problem. Idealerweise sollten Sie vor dem Rendern alle Komponenten aus der Datenbank ziehen. Aber wenn man sich die Hierarchie ansieht, macht das Erstellen von Template-Tags Sinn. Diese Schablonemarkierung wird geeignete Daten abrufen. Nehmen Sie für den Zweck dieses Problems an, dass die Datenbankabfrage aufgrund des Suchorts zwischengespeichert wird.

Answer 2

Die Lösung, die ich bisher beschlossen habe, besteht darin, eine Inclusion-Tag-Bibliothek als meine wiederverwendbare Komponente zu verwenden. Ich bleibe so weit wie möglich daran, alle Abfragen in meinem Ansichtscode einzurichten und sie in meinem Kontext vor dem Setup zu übergeben - keine Funktionen, die neue Abfragen in Vorlagen oder Tag-Bibliothekscode generieren. Die Einschlussvorlagen enthalten das gesamte Markup für das Objekt, und die Stile werden in das Hauptsite-Stylesheet übernommen, wobei meine Klassen so allgemein und wiederverwendbar wie möglich gehalten werden. Befolgen Sie dabei die Richtlinien von SMACSS. Ich refobiere Komponenten in Einschluss-Tags nur so, wie es DRY erfordert.

Ich habe zunächst meine Aufnahme Tag-Funktionen, die Parameter durch die Tag-Schablone verwendet explizit nehmen, so dass:

Seitenvorlage

<div>{% my_tag param1 param2 %}</div> 

Tag Bibliothek

@register.inclusion_tag('myapp/tagtemplates/my_tag.html') 
def my_tag(param1, param2): 
    return {'param1': param1, 'param2': param2} 

my_tag.html

<div>Blah: {{ param1 }}</div> 
<div>Blip: {{ param2 }}</div> 

... und offensichtlich richtet die Ansicht den Kontext ein.

Aber ich entschied mich stattdessen, den Parameter takes_context zu verwenden, um zu vermeiden, die Parameter in der Tag-Bibliothek explizit zu definieren. Zu viel Wiederholung für nicht genug Auszahlung in der Dokumentation. Bisher sind meine Komponenten so einfach, dass die Abhängigkeiten bei der Überprüfung der Tag-Vorlage ziemlich klar sind. Ich befürchte, dass dies bei komplizierten verschachtelten Komponenten nicht akzeptabel ist, aber ich kann meine Tag-Bibliotheksfunktionen immer ausführlich machen, wo sie sein müssen.

Ich bin nicht ganz zufrieden mit dieser Einstellung aus Sicht der Wartung. Ich mag es nicht, dass ich manuell nachverfolgen muss, welche Kontextdaten nicht mehr benötigt werden.Ich mag es nicht, dass meine CSS-Klassen sorgfältig benannt werden müssen, um Konflikte zu vermeiden.

Ich bin immer noch offen für neue Lösungen, weil ich nicht sicher bin, dass das, was ich mir vorgenommen habe, wirklich eine Best Practice ist.