Utilizarea căilor URL cu hashing vs. fără hashing în aplicațiile cu o singură pagină

Există două moduri de a accepta rutarea în aplicațiile cu o singură pagină:

• Căi URL cu hash - Rupem calea URL cu un # (Hash), astfel încât browserul să înțeleagă că este doar un fragment virtual
• Căi URL obișnuite (căi URL non-hashed) — Serverul trebuie să intercepteze cererea și să returneze index.html.

În acest articol, veți afla avantajele și dezavantajele acestor două abordări și vă va ajuta să decideți cea mai bună pentru cazul dvs. de utilizare.

Sfat: Partajați componentele dvs. reutilizabileîntre proiecte folosind „Bit” („Github”). Bit simplifică partajarea, documentarea și organizarea componentelor independente din orice proiect.

Folosiți-l pentru a maximiza reutilizarea codului, pentru a colabora la componente independente și pentru a crea aplicații care se extind.

„Bit” acceptă Node, TypeScript, React, Vue, Angular și multe altele.

Căi URL obișnuite

După aspectul lor, puteți identifica că următoarele sunt adrese URL obișnuite.

https://mysite.com/dashboard
https://mysite.com/shopping-cart

Avantaje

• Adresele URL obișnuite arată frumos și curate.
• Aceste tipuri de URL-uri au un avantaj mai bun în ceea ce privește SEO.
• Schela aplicațiilor web care utilizează cadre precum Angular acceptă acest lucru în mod implicit.
• Serverele de dezvoltare moderne (de exemplu, ng serve în Angular) acceptă și ele acest lucru.

Una peste alta, puteți vedea că utilizarea adreselor URL obișnuite este opțiunea mai bună, având în vedere suportul disponibil. Cu toate acestea, aceste avantaje vin cu un cost.

Provocări

Când luăm în considerare adrese URL obișnuite pentru aplicațiile cu o singură pagină, trebuie să vă configurați serverul web pentru a-l accepta.

• Trebuie să configurați serverul web pentru a servi index.html pentru traseele SPA.
• Deoarece nu este practic să puneți pe lista albă fiecare cale de rută SPA pe serverul web, trebuie să aibă un model separat pentru API pentru a le distinge de rutele SPA (de exemplu,/api/* alocat pentru API).
• Trebuie să aveți o grijă deosebită atunci când definiți link-urile căilor URL în SPA, deoarece ar putea duce la reîncărcările întregii pagini.
• În unele cazuri, cum ar fi găzduirea separată a front-end-ului și backend-ului, veți avea nevoie de un Gateway pentru a face rutarea bazată pe calea serverului.

Căile URL cu hash

Adresele URL cu hash vor avea următorul format. Porțiunea separată de haș se numește fragment sau ancoră.

https://mysite.com/#/dashboard
https://mysite.com/#/cart

Dacă ați început să lucrați cu SPA-uri în urmă cu câțiva ani, căile URL Hashed erau norma pe atunci. Dar lucrurile s-au schimbat în ultimii ani. SPA-urile au devenit standardul pentru dezvoltarea web, iar instrumentele și progresul tehnologic au susținut acest lucru. Acesta este motivul pentru care acum este greu să vezi o schemă URL distinctă decât cea obișnuită pentru SPA. Cu toate acestea, există mai multe avantaje cu adresele URL Hashed care merită cunoscute.

Avantaje

• Browserele nu consideră fragmentul de cale după hash ca o pagină separată. Acest comportament al browserului este ideal pentru aplicațiile cu o singură pagină, deoarece o reîmprospătare a paginii va reîncărca index.html.
• Definirea legăturilor cu hash în interfață este sigură, deoarece nu va reîncărca pagina.
• Configurarea serverului este simplă și ușor de diferențiat între cererile API și cele de tip frontend (totuși, trebuie să planificăm căile pentru activele frontend).

Dezavantaje

Când vine vorba de adrese URL Hashed, principalul dezavantaj este aspectul său.

• Unii utilizatori ar putea considera că este neobișnuit.
• Nu este cel mai bun pentru SEO.

În caz contrar, este cel mai ușor de implementat pentru SPA.

Gestionarea căilor URL în SPA

Astăzi, aproape toate cadrele SPA moderne conțin un modul de rutare cu suport încorporat pentru a gestiona modificările URL sau fragmente.

În caz contrar, va trebui să dezvoltați o soluție personalizată pentru a urmări modificările URL în SPA. Pentru a implementa un router personalizat, puteți utiliza următoarele API-uri de browser.

• API-ul Istoric — Acesta oferă acces direct la interfața istorică a browserului dvs. Vă permite să efectuați manipularea adreselor URL fără hash. Are metode precum back() , forward() care vă permit să navigați la stările anterioare sau la stările următoare pe baza istoricului de navigare.
• „Locația AP”I împreună cu ascultătorul de evenimente „onHashChange” — În această metodă, browserul va declanșa onHashChange de fiecare dată când vede o modificare hash în adresa URL. Puteți gestiona cu ușurință modificările hash fără a comunica cu serverul folosind această metodă.

rezumat

Puteți utiliza fie adrese URL hashing, fie adrese URL obișnuite pentru aplicațiile cu o singură pagină. Având în vedere avantajele și dezavantajele acestor două abordări, veți fi de acord cu mine că ambele opțiuni sunt viabile din punct de vedere tehnic.

Chiar dacă utilizați adrese URL obișnuite pentru aplicație, orice cadru sau bibliotecă de aplicații cu o singură pagină o va accepta. Prin urmare, nu trebuie să vă faceți griji cu privire la complexitățile care vin cu rutare. Dar s-ar putea să fie nevoie să te uiți la configurarea serverului pentru a susține acest lucru.

Sper că acest articol oferă o privire de ansamblu asupra utilizării acestor două tipuri de adrese URL și vă extinde înțelegerea. Dacă întâlniți întrebări, le puteți pune în comentariul de mai jos.

Alegerea este a ta!

Află mai multe