Dlaczego jedne formatki są lepsze od drugich?

Czy pisanie formatek może być sztuką? No bez przesady!

Niemniej, pisząc formatki, można robić to dobrze lub nie. Zasady czystego kodu, reguła mvc i wiele innych nie obowiązują tylko dla backendu. Pisząc formatki, nie zapominajmy o jakości kodu.

Przejdźmy zatem do konkretów. Kilka praktycznych rad:

  1. Pamiętajmy o mvc - twórzmy:

• model (mam tu na myśli view model) czyli klasę z danymi wyświetlanymi na formatce (np. DTO, listy wyświetlane w selectach, wszystkie zmienne pomocnicze),

• kontroler (tylko metody + wstrzyknięcia serwisów, no i naszego modelu),

• widok.

Często zdarza się, że kontroler zawiera również model, jest to podejście niezgodne z regułą mvc, zazwyczaj zaczyna się od samego DTO ale potem kontroler szybko puchnie i puchnie i puchnie.

  2. Każdy element ma swoje miejsce, nie mieszajmy jednego typu elementów z innymi!

Nie definiujmy stylów w pliku html, wszystkie style definiujmy w pliku css.

Wszelaki kod js opakowujmy w funkcje i wrzucajmy do pliku js.

  3. Nie duplikujmy kodu!!!

Jeżeli kusi cię by zrobić kopiuj wklej, przypomnij sobie, co pisał wujek Bob i tak, jak w kodzie tworzysz klasy abstrakcyjne dla wspólnych części kodu czy metody, które używasz wielokrotnie w różnych miejscach, tak samo frontend nie lubi duplikacji kodu. Jeżeli jakiś fragment lub podobny, będzie wykorzystany w innym miejscu, to należy stworzyć komponent. 

Tak samo jak korzystamy z gotowych klocków, jakie dają nam biblioteki (np. primefaces), tak samo, sami powinniśmy tworzyć swoje klocki i budować naszą aplikację z podzespołów. 

  4. Super! Tworzymy już komponenty, ale nie zapominajmy, aby komponent przyjmował atrybuty. Przesyłając atrybut definiujmy jego typ (możemy tu np. podać interfejs lub klasę abstrakcyjną by zwiększyć stosowalność komponentu). Stworzenie komponentu i zaszycie w nim "beanów", to utrata elastyczności i reużywalności komponentu. Z tego samego względu warto tworzyć komponenty o mniejszej odpowiedzialności.