5 najczęstszych pomyłek programistów w Laravel 5

Kto nie pracuje, ten się nie myli. Pomyłki i błędy nawet w pracy programistów nie są rzadkością i trzeba uznać je za normalną i naturalną kolej rzeczy. By jednak błędy mogły być wykluczone, warto pochylić się i przeanalizować te, które pojawiają się najczęściej i są powtarzalne. O pomyłkach w kodzie aplikacji budowanych w oparciu o Laravel 5 słów kilka i wskazówkach, by pomyłek uniknąć.

Walidacja w kontrolerach

Bardzo często developerzy, pracujący na Laravel 5, umieszczają walidację parametrów przychodzących w żądaniu do serwera w tak zwanych metodach kontrolera. W wersji starszej frameworka Laravel, czyli Laravel 4 takie działanie jest w pełni akceptowalne. Ale Laravel 5 wprowadził zmianę w postaci Form Request. I to miejsce jest odpowiednie, w którym należy umieścić walidację. Każda klasa ma metodę Rules. I ją należy odpowiednio wykorzystać. Tu są zawarte szczegółowe informacje o tym, w jaki sposób należy prawidłowo poza kontrolerem zaimplementować walidację.

Link do wykorzystania:

https://mattstauffer.com/blog/laravel-5.0-form-requests

O kontrolerze słów kilka

Bardzo poważnym i niestety częstym błędem jest umiejscowienie dużej części algorytmów biznesowych w warstwie kontrolerów. Winą za taką pomyłkę jest zazwyczaj brak doświadczenia, jak również pomysłu, jak wykorzystać kod, który nijak nie pasuje, by bez problemu móc umieścić go w Eloquent. Dlatego developerzy pakują go w kontrolerze, a wtedy ujawnia się problem ze zbyt rozbudowanym kontrolerem. Warto przy okazji zwrócić uwagę na popularne Repositories. Jednak ich stosowanie wymaga odpowiedniej rozwagi oraz świadomości, do czego one są przydatne. Gdy developer nie planuje zmiany sposobu, w jaki łączy się z bazą lub będzie przenosić kod do innego frameworka, takie działania nie ma większego sensu. W bazie powinno się maksymalnie wykorzystywać możliwości, jakie daje klasa Eloquent. Natomiast algorytmy, które nie są związane bezpośrednio z bazą danych, należy stosować w Managerach, których podstawą jest wzorzec Fasada.

Dzięki temu kod, który znajduje się w kontrolerze, zostanie uproszczony do wywołania metody z managera oraz nadaniu jego wyników do widoku lub jako JSON – odpowiedź na żądanie. Klasy managera powinny zostać umiejscowione w katalogu Services.

Kod w widokach

Do złych praktyk należy zastosowanie kodu php bezpośrednio w widokach. Developerzy robią tak, by pobrać lub wyliczyć pewną ściśle określoną zmienną, która nie została przekazana w kontrolerze. Na przykład jest to ukazanie awatara zalogowanego użytkownika we wspólnym widoku strony. Laravel 5 posiada tak zwany ViewComposer. Tutaj developer powinien umieścić zapoczątkowaną zmienną w odpowiednią wartość, a następnie przekazać ją do widoku. Tak też można przekazać daną wartość do wielu widoków, ale takich, które tę jednostkę mają mieć wspólnie. Dużo przydatnych informacji na ten temat znajduje się tutaj: https://laravel.com/docs/7.x/views.

Skrypty JavaScript i stylów w public

Opanowanie skryptów JavaScript oraz CSS utrudnia zamieszczanie ich kodu od razu w public. A framework Laravel już od wersji 5 ma wbudowanego GULP-a oraz Elixir, który jest pomocny przy jego konfiguracji. Kod JavaScript, a także style powinny znaleźć się w folderze /resources/assets/ js albo sass. Można je wtedy uporządkować w odpowiednio nazwane pliki, a dzięki temu łatwiej się zobrazuje przynależność danego kodu. Z pomocą GULP natomiast te pliki można odpowiednio połączyć. Można to wykonać do jednego pliku. Takie połączenie zdecydowanie przyspieszy ładowanie skryptów do przeglądarki.

Wykorzystanie Fasad Laravela poza kontrolerami i middleware

Wykorzystanie Fasad w obrębie kontrolerów i middleware jest prawidłowe, ponieważ są stałą, bez możliwości przeniesienia częścią Laravela. Jednak poza kontrolerami nie może do takich działań dochodzić. W każdym miejscu, jakie jest poza kontrolerami, wykorzystuje się Dependency Injection. Dlaczego? Ponieważ zdecydowanie prostsza staje się kontrola nad kodem, a także wzrasta jego skalowalność. Uproszczone zostaje również pisanie testów, a także zrozumienie samego kodu.