Promisiunea fără JavaScript se verifică în răspuns

O pagină fără componente interactive poate primi totuși JavaScript de la cadrul de dezvoltare. Formula „fără JavaScript în mod implicit” devine utilă când răspunsul livrat o confirmă. Schimbarea Fresh privind pornirea condiționată a codului client oferă o delimitare concretă: verificați ce emite pagina pentru funcțiile pe care le folosește. Absența unei insule din codul-sursă nu dovedește ce răspuns primește browserul.

Anunțul Fresh 2.3, din 24 aprilie 2026, spune că paginile anterioare primeau un mic script de pornire chiar și fără insule sau actualizări parțiale. Schimbarea verifică ambele funcții înainte să îl introducă. Propunerea de modificare #3696 a fost deschisă la 21 martie și integrată la 29 martie. Sunt etape ale implementării, distincte de anunțul lansării din aprilie. Exemplul istoric nu stabilește ce versiune este instalată pe un anumit site.

Definiți promisiunea pentru fiecare pagină

O insulă este un motiv pentru care cadrul pornește comportamentul din browser. Navigarea pe client prin actualizări parțiale (f-client-nav) este un alt motiv. O pagină poate să nu aibă prima funcție, dar să o ceară pe a doua. Dacă numiți orice pagină fără insule „pagină fără scripturi”, reuniți funcții diferite sub o etichetă comodă. Un comportament implicit util trebuie să precizeze ce funcții pot activa codul client și ce se întâmplă când niciuna nu este prezentă.

Unitatea de verificare devine astfel pagina individuală în starea relevantă. Un șablon comun poate adăuga navigare pe client unei rute cu conținut static. O componentă condiționată poate schimba cerințele unui răspuns altfel asemănător. Dacă priviți numai fișierul rutei, puteți rata aceste dependențe. Urmăriți compunerea paginii suficient de departe pentru a explica răspunsul pe care îl primește efectiv cititorul.

Nu este nevoie ca toate paginile să aibă aceeași regulă. O pagină de documentație poate folosi navigare obișnuită, iar un ecran al aplicației poate folosi intenționat navigare pe client. Contează ca alegerea să fie conștientă. Aplicația trebuie să aibă o explicație pentru funcție și pentru codul pe care aceasta îl cere. Sloganul cadrului nu poate înlocui explicația pentru pagini care au scopuri diferite.

Dovezile cuprind scripturi și preîncărcări

Lansarea descrie un răspuns fără eticheta de script a cadrului și fără antete de preîncărcare a modulelor când nu este folosită niciuna dintre cele două funcții. Sunt lucruri separate de verificat. Eliminarea unui script de pornire vizibil, cu păstrarea preîncărcărilor, ar lăsa alt răspuns decât cel descris. O verificare care caută numai un nume familiar de script poate rata o parte din promisiune.

Aplicația poate adăuga propriile scripturi separat de pornirea condiționată a codului Fresh. Analiza traficului, un element încorporat sau un modul inclus manual cere o explicație proprie. Cadrul își poate condiționa contribuția fără să dovedească absența JavaScript din documentul complet. Precizați subiectul afirmației: codul emis de cadru și întregul cod emis de aplicație au domenii legate, dar diferite.

Pentru o verificare viitoare, comparați o pagină fără niciuna dintre funcții cu una care folosește o insulă și cu una care folosește navigare parțială. Inspectați marcajul și antetele livrate pentru fiecare. Consemnați configurația aplicației lângă observații, astfel încât alt responsabil să poată repeta verificarea. Aceasta este o verificare propusă, fără să afirme că asemenea pagini au fost construite sau măsurate pentru articol.

Separați conținutul răspunsului de performanță

Absența scriptului de pornire este un fapt despre răspuns. O vizită mai rapidă este o măsurătoare privind o anumită pagină și un anumit mediu. Trecerea de la primul fapt la a doua afirmație cere dovezi despre cereri, memorarea în cache și sarcina utilizatorului. Schimbarea justifică investigarea performanței; nu stabilește o îmbunătățire universală a rezultatelor afacerii sau a timpului de încărcare pe un site anume.

Separarea ajută echipa să decidă și dacă un script rămas este justificat. Un mic script comun de pornire poate fi un compromis rezonabil pentru navigare uniformă într-un produs. Eliminarea lui poate schimba experiența de navigare așteptată de utilizatori. Echipa poate alege conștient compromisul fără să pretindă că fiecare răspuns are zero JavaScript. O denumire onestă sprijină mai bine decizia decât transformarea numărului minim de scripturi în singurul obiectiv.

Și contraargumentul are limite. Uniformitatea justifică păstrarea unei funcții acolo unde produsul are nevoie de ea. Același cod client aplicat peste tot poate fi comod pentru responsabilii aplicației, fără să ajute prea mult cititorul care urmează un link obișnuit. Discutați cerința concretă de navigare înainte să impuneți eliminarea sau o excepție. Beneficiul are nevoie de un responsabil care îl poate explica.

Păstrați promisiunea verificabilă în timp

O condiție utilă de acceptare descrie rezultate observabile pentru o categorie definită de pagini. Categoria poate exclude insulele și navigarea pe client, iar verificarea poate acoperi contribuția cadrului la scripturi și preîncărcări. Condiția rămâne valabilă după reorganizarea componentelor. Este mai stabilă decât o convenție care presupune că un anumit director va conține mereu rute statice.

Modificările șabloanelor comune merită atenție fiindcă pot schimba multe pagini simultan. Adăugarea navigării pe client într-un înveliș comun schimbă necesarul de funcții chiar dacă nu se modifică niciun articol sau fișier de documentație. Verificarea ar trebui să facă vizibilă urmarea pentru persoana care răspunde de regula paginii. Altfel, comportamentul implicit poate devia în timp ce fiecare modificare pare inofensivă autorului ei.

Într-un proiect software la comandă, precizați cerința privind răspunsul alături de cerința de navigare. Alegeți apoi comportamentul care le satisface pe ambele, cu o excepție explicită acolo unde codul comun servește produsului. Schimbarea istorică Fresh este utilă fiindcă permite verificarea directă a delimitării. Responsabilitatea continuă este păstrarea acordului dintre promisiunea aplicației și răspunsul pe care îl livrează efectiv.