Auto-prefix URL — una piccola cosa che fa risparmiare minuti

Inserisci nel modulo allegro.pl. Clicchi. E poi?

Nella maggior parte degli abbreviatori ricevi in questo momento un messaggio di errore. Qualcosa tipo "questo non è un URL valido". Perché manca https:// all'inizio. Quindi torni indietro, aggiungi il protocollo, clicchi di nuovo e solo ora hai il tuo link breve.

cutty.dev non lo fa. Semplicemente aggiunge https:// e va avanti, come se nulla fosse.

So come suona. Come una funzionalità che a malapena merita un paragrafo, per non parlare di un intero post. Eppure sono qui a scriverne, perché proprio questo piccolo dettaglio è per me un piccolo manifesto di come io pensi in generale alla costruzione di uno strumento di auto-prefix URL e di tutto il resto di queste facilitazioni invisibili.

Due secondi contro venti

Contiamo. Davvero, basiamoci sui numeri, perché altrimenti è solo chiacchiericcio.

Percorso primo: incolli, hai il link, chiudi la finestra. Due secondi. Forse tre.

Secondo percorso: incolli, errore, leggi il messaggio (un secondo o due per capire di cosa si tratta), aggiungi il protocollo, clicchi di nuovo, solo ora il link. Quindici, venti secondi. Più quel piccolo momento di irritazione, quel silenzioso "ah già, il protocollo", che singolarmente non costa nulla, ma si accumula.

E ora moltiplica per quante volte al mese incolli un indirizzo. Per me sono decine. Per chi gestisce i link professionalmente — centinaia. All'improvviso, quel dettaglio "appena degno di nota" si accumula in minuti al mese. Per persona.

Questa è proprio l'aritmetica che la maggior parte delle persone trascura, perché ogni singolo caso sembra troppo piccolo per meritare attenzione.

Cosa c'è effettivamente sotto il cofano

Il meccanismo è banale e non lo nascondo affatto. Incolli il testo nel campo. Prima che qualsiasi cosa venga inviata al server, un frammento di JavaScript controlla se ciò che hai digitato inizia con qualche protocollo — http://, https://, ftp://, mailto:, qualunque cosa. Se non inizia con uno di essi, il sistema assume che tu intenda un dominio comune e aggiunge https:// all'inizio.

Nella pratica:

• allegro.pl diventa https://allegro.pl
• github.com/twoj-profil/projekt in https://github.com/twoj-profil/projekt
• www.gazeta.pl in https://www.gazeta.pl

E se il protocollo è già presente, anche se strano, il sistema non lo sovrascrive. Lo lascia lì e continua a controllare cosa farne. http://example.com passa (consentito). ftp://example.com finisce nel cestino, perché accettiamo solo http e https. E javascript:alert(1) viene eliminato immediatamente, perché non è un indirizzo, ma un tentativo di iniettare qualcosa di nocivo (classico XSS, grazie, ma no).

Perché io ce l'ho, e metà del mercato no

Qui la cosa si fa interessante, perché la risposta è un po' buffa.

Il modo standard per validare un indirizzo nel browser è il costruttore new URL(string). E questo costruttore è rigido. Senza compromessi. Se manca il protocollo — lancia un errore. new URL("allegro.pl") ti restituisce semplicemente un TypeError e basta.

E sai una cosa? Questo è un comportamento corretto. Per la stragrande maggioranza delle applicazioni, è esattamente ciò che desideri. Ma in un modulo per l'accorciamento dei link, dove una persona copia l'indirizzo dalla barra del browser o da un messaggio di qualcun altro, questa rigidità si trasforma da vantaggio in ostacolo. Improvvisamente, uno strumento che dovrebbe farti risparmiare tempo ti costringe a correggere qualcosa che, in realtà, comprende perfettamente.

Aggirare questo è letteralmente poche righe:

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalej leci normalna walidacja przez new URL(normalized)
}

Cinque righe. Una dozzina di secondi in meno di attrito, al giorno, per chiunque incolli degli indirizzi. Sinceramente non so perché non sia uno standard ovunque. Sospetto che il motivo sia che "il costruttore URL funziona semplicemente così" e nessuno ha avuto voglia di toccarlo. Inerzia, non cattiva volontà.

Una piccola digressione su cosa significhi "standardmente"

Perché questa storia con new URL() è un ottimo esempio di qualcosa di più ampio. Tantissime cose che nel software sono considerate "si fa così", in realtà sono "è venuto fuori così dalle impostazioni predefinite di qualche libreria che nessuno ha messo in discussione". La strict mode del costruttore non è una decisione dei progettisti di cutty né della concorrenza — è una decisione degli autori della specifica URL, presa in un contesto completamente diverso, per utilizzi completamente diversi.

E poi l'intero mercato eredita questa scelta predefinita e la chiama "standard". Ho l'impressione che i prodotti migliori nascano esattamente in quei luoghi in cui qualcuno si è fermato e ha chiesto: un momento, questo comportamento serve davvero al mio utente o solo alla mia libreria? Nella maggior parte dei casi la risposta è: alla libreria. Ed è allora che vale la pena, con cinque righe di codice, passare dalla parte dell'essere umano.

Questi dettagli sono più di quanto sembri

L'auto-prefix è solo uno dei tanti elementi che non troverai in alcuna lista di funzionalità. Perché se venissero inseriti lì, ognuno di essi sembrerebbe ridicolmente piccolo:

• rimozione degli spazi prima della validazione, in modo che uno spazio accidentale alla fine dell'indirizzo incollato non rovini tutto
• mantenimento dell'ancora, ovvero #section in https://example.com/page#section non scompare dopo l'accorciamento
• i parametri di query (?utm_source=test) passano interamente, nulla viene tagliato lungo il percorso
• domini con caratteri polacchi, źdźbło.pl, vengono convertiti automaticamente in punycode
• lettere polacche nella propria estensione vengono convertite in ASCII (różowy-link diventa rozowy-link)
• protocolli pericolosi — javascript:, data:, file: — rifiutati con un messaggio specifico e comprensibile

(È ancora prevista l'automatica promozione di http:// a https://, quando il server di destinazione supporta la crittografia. Questo al momento non è ancora attivo dal vivo, quindi non farò finta di nulla.)

Ciascuno di questi dettagli fa risparmiare a qualcuno cinque, dieci, trenta secondi e un sospiro. Singolarmente nulla. Insieme fanno la differenza tra "funziona OK" e "mi piace usarlo".

Cosa vorrei ancora guadagnare

Lista dei desideri per il futuro, perché pensarci mi dà semplicemente gioia:

• incollamento intelligente — rilevare l'indirizzo nascosto all'interno di una frase ed estrarre solo l'URL tra le parole
• incollamento in blocco — elenco di indirizzi, uno per riga, e per ognuno un link breve separato immediatamente
• suffissi suggeriti — proporre tre slug personalizzati tra cui scegliere in base al titolo della pagina di destinazione
• anteprima Open Graph subito dopo l'incolla, ancora prima di cliccare su "accorcia"

Ognuno di questi è di nuovo una "funzione di cinque righe che non sembra nulla". E tutti insieme? È proprio quel confine tra uno strumento che va bene e uno che usi ogni giorno senza pensarci. Se vuoi vedere come funziona ora, incolla in cutty.dev qualsiasi cosa senza protocollo — allegro.pl, github.com, news.ycombinator.com — e vedrai che non ti pone alcun ostacolo.

Infine, un po' personalmente

Ho pensato a lungo che i prodotti vincessero grazie a grandi funzionalità. Quella singola cosa d'effetto che si può mostrare in una slide e di cui la gente scriverà. E sì, a volte è così.

Più a lungo costruisco cutty, più sento con forza che la fedeltà dell'utente nasce altrove — in quelle centinaia di microsecondi che nessuno nota consapevolmente. Non ricordi che lo strumento ha aggiunto da solo https://. Ricordi solo l'impressione generale che "si usa bene in qualche modo", "non infastidisce". Questa impressione non nasce dal nulla. È composta da decine di decisioni di cinque righe che, singolarmente, nessuno difenderebbe come "degne del proprio tempo".

Forse è proprio in questo che consiste l'artigianato. Non in un unico grande gesto, ma nella determinazione di schierarsi, volta dopo volta, dalla parte dell'utente davanti a un modulo — anche se si tratta di miseri due secondi. E tu? Cosa ti ha fatto arrabbiare ultimamente in qualche strumento, in modo così piccolo da vergognarti quasi ad ammetterlo? Perché di solito è proprio lì che si trova il miglior lavoro da fare.