Szeroka Perspektywa Full-Stack Web Developmentu: Walidacja po stronie front-endu

0:00W tej lekcji przyjrzymy się bardzo istotnym temu elementowi przepływu

0:03informacji w naszej aplikacji, jakim jest walidacja.

0:07Mianowicie, jak widać przygotowałem tutaj

0:08bardzo prostą aplikację umożliwiającą dodanie komentarza.

0:12Pominąłem tutaj wszelkie złożoności, aby nie utrudniać tego przykładu.

0:16Musisz jednak wiedzieć, że mamy tutaj

0:17aplikację działającą zarówno po stronie klienta, jak i serwera.

0:21W przypadku tego pierwszego tak naprawdę jest to jeden komponent, który odpowiada

0:25za wyświetlanie i obsługę logiki formularza.

0:27W przypadku serwera mamy do czynienia z

0:29jednym endpoint em, który przyjmuje dane na temat formularza, a następnie zapisuje

0:34je w pamięci aplikacji w formie takiej tablice.

0:37Zatem nie mamy tutaj do czynienia ani z bazą danych, ani z autoryzacją, ale

0:41zasadniczo funkcja dodawania komentarza powinna tutaj działać.

0:45Zatem jeżeli teraz przyjrzymy się jak to

0:47wygląda po stronie frontendu, to myślę, że jeszcze będzie nam potrzebna konsola po

0:51to, aby podejrzeć sobie co tutaj dokładniej się dzieje.

0:54Przede wszystkim zadbałem o to, aby

0:56użytkownik nie mógł dodać pustego komentarza.

0:59W momencie gdy próbuje to zrobić, zostaje

1:01wizualnie poinformowane o fakcie, że coś jest nie tak.

1:04Naturalnie moglibyśmy wyświetlić dla niego

1:06dodatkową informację, ale wydaje mi się, że jest to wystarczająco wymowne.

1:11W każdym razie najważniejsze jest to, że na backend nie trafiają puste dane.

1:16Drugim wątkiem, na które trzeba tutaj zwracać uwagę jest natychmiastowy feedback

1:20dla użytkownika w momencie, gdy dodaję formularz.

1:23Mianowicie zamiast czekać na to, aż uzupełnij formularz, a następnie go wyślij

1:27i dopiero wtedy otrzyma informację o błędzie, informujemy go o tym natychmiast.

1:31Teraz, jeżeli zdecydujemy się na dodanie

1:33komentarza, to zwróci uwagę co tutaj dokładnie się dzieje.

1:37Po pierwsze mieliśmy tutaj jakieś zapytanie, które wróciło odpowiedź ze

1:41statusem 201 i wewnątrz niego poza treścią naszego komentarza pojawił się również

1:46identyfikator, który wyświetli liczbę w tym miejscu.

1:49W momencie gdy dodamy kolejny komentarz, on również zostanie tutaj odpowiednio

1:53wyświetlony, przy czym w jego przypadku identyfikator się zmieni.

1:57Chciałbym tutaj w tym momencie zwrócić

1:59Twoją szczególną uwagę na to, co tutaj dokładnie się dzieje.

2:02Przede wszystkim jeżeli chodzi o nasz

2:03komponent, to zauważ, że tutaj w momencie wysłania zapytania do serwera o zapisanie

2:08formularza odbieramy dane, które nam zwraca, a następnie to te dane

2:13wykorzystujemy po to, aby wyświetlić je po stronie frontendu.

2:16Teoretycznie moglibyśmy zrobić tak, aby wykorzystać dane wprowadzone przez

2:21użytkownika po stronie frontendu i to na nich opierać cały frontend.

2:25Rzecz w tym, że jeżeli teraz dodamy taki

2:27komentarz, to okaże się, że teoretycznie mogłoby to działać, ponieważ komentarz

2:32wyświetlił się i ten identyfikator też nie byłby nam tutaj potrzebny.

2:36Ale wyobraź sobie sytuację, w której

2:38chcemy dorobić możliwość edytowania tego komentarza W momencie, gdy opieramy się na

2:43danych pochodzących z frontendu, nie mamy informacji o identyfikatorze i tym samym

2:48dorobienie takiego przycisku nie jest możliwe.

2:51Jednocześnie też w niektórych przypadkach

2:53mogłoby się wydarzyć tak, że po stronie backendu dojdzie do jakiejś formy

2:56transformacji danych, które zostały przesłane przez użytkownika, np.

3:01transformacji składni Markdown.

3:03Jeżeli teraz ponownie dodamy komentarz, no

3:05to pomimo tego, że w naszej bazie danych znajduje się coś zupełnie innego, to po

3:10stronie frontendu wyświetlamy coś zupełnie innego.

3:13Oznacza to mniej więcej tyle, że zasada, o której mówiłem, dotycząca tego, aby

3:18backend był źródłem nie ma tutaj zastosowania.

3:21I tym samym doprowadzamy do obecnie nieprzyjemnych błędów.

3:24Jeszcze akurat w tym przypadku mamy do

3:26czynienia z komentarzem, więc teoretycznie trochę trudno tutaj cokolwiek popsuć.

3:31Ale wyobraź sobie, że logika Twojej aplikacji jest nieco bardziej złożona i

3:35nagle okazuje się, że zaczynają pojawiać się błędy, które naprawdę trudno naprawić.

3:40W związku z tym, jeżeli chodzi o walidację

3:42danych, to pamiętaj proszę o tym, aby przede wszystkim zadbać o to, aby.

3:46Oczywiście uwzględniając decyzje projektowe designerów oraz UX designerów

3:51uwzględnić to, w jaki sposób informujesz użytkownika o błędzie.

3:55Następnie musisz upewnić się, że

3:57przypadkowe dane nie trafią do Twojej aplikacji.

4:00Mowa tutaj chociażby o pustej treści komentarza.

4:03No i ostatecznie pamiętaj proszę, aby tak

4:05zaprojektować backend, aby nie tylko zapisywać informacje, ale również wracać

4:10do klienta w takiej formie, by mogły zostać wyświetlone użytkownikowi, a

4:14dodatkowo ułatwiły Ci późniejszą pracę z nimi.

4:17Mam tutaj na myśli chociażby wspomnianą wcześniej edycję.

4:21Jednocześnie jako full stack developer

4:23musisz zadbać jeszcze o pewne rzeczy, których tutaj pozornie nie widać.

4:27Otóż wyobraź sobie teraz sytuację, że masz

4:30do czynienia z użytkownikiem, który chce zrobić trochę problemu.

4:34Zamiast dodać zwyczajny komentarz, dodaje np.

4:37komentarz HTML.

4:38Poza tym nic nie stoi na przeszkodzie, aby umieścić tutaj również jakiś skrypt.

4:43W momencie, gdy w pełni zaufasz użytkownikowi i zapiszesz te informacje

4:47bezpośrednio w bazie danych, to w niektórych sytuacjach możesz doprowadzić

4:51do tego, że inni użytkownicy zobaczą coś, czego zobaczyć nie powinni.

4:55Z tego powodu warto zabezpieczyć się na takie sytuacje.

4:58Ale coś takiego.

5:00Po stronie backendu.

5:01Mianowicie zwróćcie uwagę na fakt, że

5:04jeżeli dodam sobie raz jeszcze komentarz, a następnie zobaczę, że tak naprawdę jest

5:09to zapytanie typu post na adres localhost 3000.

5:13Zatem teraz mogę te informacje wykorzystać

5:16po to, aby przesłać tutaj zupełnie swoje dane np.

5:20tym razem. Pomimo tego, że nasza aplikacja blokuje

5:23puste komentarze, to w tym przypadku będę chciał taki wysłać.

5:27Zobaczy, że otrzymaliśmy tutaj status 201,

5:30a to oznacza, że komentarz został zapisany w bazie.

5:33Można powiedzieć, że akurat w tym przypadku nie jest to aż tak duży problem,

5:37ale jednocześnie po stronie backendu również możesz popełnić pewne błędy, które

5:42mogą doprowadzić do różnego rodzaju nadużyć.

5:45Z tego powodu w jednej z kolejnych lekcji

5:47również przyjrzymy się temu, w jaki sposób możemy kontrolować dane po stronie

5:51backendu, tak aby nie trafiło do nas coś, czego nie chcemy.

5:54A jeżeli chodzi o frontend, to by było na tyle.

5:57Raz jeszcze tylko podkreślę, aby zadbać o

6:00to, by użytkownik natychmiast otrzymywał feedback dotyczący podejmowanych przez

6:05niego akcji, a następnie też abyśmy zadbali o to, aby to backend był zawsze

6:09źródłem na temat informacji wyświetlanych po stronie frontendu.

6:14Teraz dziękuję Ci za uwagę i zapraszam do kolejnej lekcji.