Mie mi se pare redundant să fac validarea și in browser, din moment ce oricum trebuie să o fac și pe backend. Că doar nu las nevalidate pe server-side request-urile venit din jungla internetului, right?
Oh, evident, nici nu se pune problema să nu se facă o validare server side.
Dar pentru UX este bună o validare și pe client.
De exemplu, ce faci dacă ai un formular cu fișiere? Dacă userul greșește alt câmp, va trebui să urce iar fișierul/fișierele. Dacă fișierul este mare, aștepți câteva secunde până se face validarea pe server etc.
Dacă ai validare pe client scapi de problemele astea. Dacă un utilizator este suficient de răuvoitor tech-savy să facă submit la form trecând de validarea de browser, cel mai probabil nu-l vor deranja problemele de mai sus.
Pentru scenariile de tipul ăsta prefer să fac submit-ul prin ajax, nu submitez direct form-ul.
De fapt în general prefer submit prin ajax, pentru că în felul ăsta nu ies de pe pagină, iar în cazul în care validatoriul de pe server-side prinde erori mi le întoarce prin json și pot să indic userului ce s-a întâmplat, cu lux de amănunte.
În felul ăsta am un singur validator, deci am consecvență și mai puțin de muncă, mai ales dacă faci modificari în form, caz în care va trebui să-ți amintești să implementezi validare în două locuri.
cam asta-i metoda folosita si de mine. ori construiesc validarile pt fe din be la deploy (pt dev o sa fie mereu dinamice) ori fac requestul si in caz de buba afisez erorile in formular.
ps: submitez? wth e un submitat? ruda cu comitatul cumva?
inlocuirea cuvintelor deja existente in romana cu variante romglizate nu-i imbogatire. ca sa nu mai zic ca de fapt si de drept, in cel mai fericit caz, postezi.
tot are mai mult sens decat “a submita”. si n-am spus ca-i termenul corect, am spus doar ca e o exprimare mai des intalnita si deci mai acceptata.
hai sa nu continuam, pur si simplu m-a amuzat submitarea si mi-am adus aminte ca am auzit si de comitate.
Validarea corecta e doar daca se face in amandoua partile la runtime (pentru string-uri, adica min/max length, caractere, input masking la numere de telefon, format la data si ora) fiindca exista o probabilitate ca sa se intample urmatoarele:
Domeniul sau ip-ul serverului poate fi schimbat pe alta destinatie, poate alt VM cu un server similar care iti trimite 200 la fiecare request de validare. (am intalnit situatia aceasta inclusiv pe ceva retea mobila in roaming, pur si simplu un domeniu ducea la alt server care avea certificat valid)
Ai un load balancer/gateway care raspunde gresit cu 200 la fiecare request.
Am intalnit scenariile acestea de N-ori pe AWS si Google Cloud. Desigur ca nu va functiona nici formularul, dar va fi foarte ciudat pentru utilizator.
(Atentie, daca afisati un field gol din acest motiv si e vorba de ceva care e negativ daca exista si pozitiv daca nu exista, de exemplu alerte/erori poate fi o problema mare - trebuie validat mereu ca datele de pe backend care vin sunt valide, nu numai user input-ul)
Serverul de obicei nu are de unde sa stie limba de pe UI, deci cea mai buna solutie e ca serverul sa raspunda mereu cu constante care dupa se traduc pe FE ori de pe un server care are traducerile ori dintr-un fisier json.
Imi place implementarea din articol cu loader la validare si formularul blocat cat timp nu s-a validat unicitatea username-ului.
Folosirea componentelor native e utila in special pe mobile, cand nu vrei sa afisezi un input cu litere cand poti introduce doar numere sau nu vrei ca omul sa scrie numele unui oras cand poate sa il selecteze. Plus autocomplete.
Exista solutii pentru validari dupa OpenAPI daca exista un pipeline facut ca sa se ia dintr-un loc in altul.