Django: Implementacja zagnieżdżonego, wielokrotnego użytku projektu komponentu

Question

Pracuję nad dużą aplikacją społecznościową w Django, gdzie wielokrotnie używam pewnych składników front-endowych, a często z funkcjonalnością zaprojektowaną w taki sposób, że komponenty niestandardowe zawierają inne niestandardowe komponenty, które mogą zawierać jeszcze mniejsze podkomponenty (ad infinitum). Wszystkie te komponenty są zazwyczaj generowane dynamicznie. Próbuję znaleźć najlepszy sposób na to, aby stworzyć architekturę w środowisku Django, dzięki czemu moje komponenty są łatwe w utrzymaniu i mają przejrzyste interfejsy programistyczne. Opieranie się w dużej mierze na kontekście globalnym wydaje się być przeciwieństwem tego, jednak widzę zalety w unikaniu zbędnych zapytań, robiąc je wszystkie naraz w widoku.

Niestandardowe znaczniki szablonu dołączania wydają się być dobrym rozwiązaniem do implementowania komponentów, ale zastanawiam się, czy wysoce zagnieżdżone tagi szablonów mogą powodować problemy z wydajnością, czy też architektura parsowania zapobiega temu? Jaki jest najlepszy sposób na to, aby było to samo-dokumentowanie na poziomie widoku, jaki kontekst jest potrzebny do renderowania głównego szablonu strony, niestandardowych znaczników i wszystkiego? Wyobrażam sobie, że to mały koszmar, aby spróbować poprawnie zachować kod, aby skonfigurować kontekst szablonu. Na koniec, jaki jest najlepszy sposób na utrzymanie CSS dla tych komponentów?

Możesz zaproponować inne zalecane podejścia do tworzenia projektu zagnieżdżonego komponentu.

Answer 1

To interesujący problem. Najlepiej byłoby wyciągnąć wszystkie komponenty z bazy danych przed renderowaniem. Ale patrząc na hierarchię, tworzenie znaczników szablonów ma sens. Ten tag szablonu spowoduje pobranie odpowiednich danych. Założono dla celów tego problemu, że zapytanie bazy danych zostanie zbuforowane ze względu na lokalizację wyszukiwania.

Answer 2

Rozwiązaniem, które do tej pory zdecydowałem, jest zastosowanie biblioteki znaczników włączenia jako mojego zestawu komponentów wielokrotnego użytku. Staram się ustawiać wszystkie zapytania w moim kodzie widokowym i przekazywać je w ustawieniach wstępnych w moim kontekście - bez funkcji generujących nowe zapytania w szablonach lub w kodzie biblioteki znaczników. Szablony włączania zawierają wszystkie znaczniki dla elementu, a style są umieszczane w głównym arkuszu stylów witryny, zachowując moje klasy jako ogólne i możliwe do wielokrotnego użycia, zgodnie z wytycznymi SMACSS. Odwzorowuję komponenty na znaczniki włączające tylko, gdy wymaga tego DRY.

ja początkowo moje funkcje tag włączenia wyraźnie wziąć parametry używane przez szablon tag, tak że:

Szablon strony

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

biblioteka Tag

@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> 

... i oczywiście widok ustawia kontekst.

Ale zdecydowałem zamiast tego użyć parametru takes_context, aby uniknąć jawnego definiowania parametrów w bibliotece znaczników. Zbyt wiele powtórzeń za niewystarczającą zapłatę w dokumentacji. Do tej pory moje komponenty są na tyle proste, że zależności są całkiem jasne po sprawdzeniu szablonu znacznika. Obawiam się, że może to nie być akceptowalne w przypadku skomplikowanych komponentów zagnieżdżonych, ale zawsze mogę sprawić, że moje funkcje biblioteki znaczników będą pełne, gdzie muszą być.

Nie jestem całkowicie zadowolony z tej konfiguracji z punktu widzenia konserwacji. Nie podoba mi się, że będę musiał ręcznie śledzić, które dane kontekstowe nie są już potrzebne.Nie podoba mi się to, że moje klasy CSS będą musiały być starannie nazwane, aby uniknąć konfliktów.

Wciąż jestem otwarty na nowe rozwiązania, ponieważ nie jestem pewien, że to, co zdecydowałem, jest najlepszą praktyką.