Auto-prefix URL — un detall que estalvia minuts

Escriu allegro.pl al formulari. Fes clic. I què?

En la majoria de acortadors, en aquest moment reps un missatge d'error. Algo com a "aquesta no és una URL correcta". Perquè falta el https:// al principi. Així que tornes enrere, afegeixes el protocol, fas clic una altra vegada, i només llavors tens la teva URL curta.

cutty.dev no fa això. Simplement enganxa https:// i continua com si res.

Sé com sona. Com una funcionalitat que a duras no mereix ni un paràgraf, ni parlar d'una entrada sencera. I, tanmateix, aquí estic escrivint sobre això, perquè precisament aquest detall és per a mi un petit manifest de com penso en general sobre la construcció de l'eina auto-prefix URL i de tota la resta d'aquestes facilitats invisibles.

Dos segons contra vint

Calculem. Realment, amb números, perquè si no només és parlar.

Primer camí: enganxes, tens l'enllaç, tancues la finestra. Dos segons. Potser tres.

Segon camí: enganxes, error, llegeixes el missatge (un segon o dos per entendre de què es tracta), afegeixes el protocol, fas clic una altra vegada, i només ara l'enllaç. Quinze, vint segons. Més aquest petit moment d'irritació, aquell silenci de "ah, és veritat, el protocol", que no costa res per separat, però s'acumula.

I ara multipliqueu per quant vegades a l'any enganxeu alguna adreça. En el meu cas, són desenes. Per algú que gestiona enllaços professionalment — centenars. De sobte, aquest detall "apenas digne de menció" s'acumula en minuts mensuals. Per persona.

Aquesta és precisament l'aritmètica que la majoria de la gent passa per alt, perquè cada cas individual sembla massa petit com per preocupar-se-ne.

Què hi ha realment sota tot això

El mecanisme és banal i no ho oculto gens. Enganxes el text al camp. Abans que qualsevol cosa arribi al servidor, una part de JavaScript comprova si el que has escrit comença amb algun protocol — http://, https://, ftp://, mailto:, el que sigui. Si no comença així, el sistema supposeix que et refereixes a un domini normal i enganxa https:// al principi.

En la pràctica:

• allegro.pl es converteix en https://allegro.pl
• github.com/twoj-profil/projekt en https://github.com/twoj-profil/projekt
• www.gazeta.pl en https://www.gazeta.pl

I si el protocol ja és allà, encara que sigui estrany, el sistema no el sobrescriu. El deixa i continua comprovant què fer amb això. http://example.com passa (permès). ftp://example.com va a la poumbra, perquè només acceptem http i https. I javascript:alert(1) surt immediatament, perquè això no és una adreça, és un intent de injecció de sesuatu malastre (XSS clàssic, gràcies, no).

Per què ho tinc jo, i la meitat del mercat no

Aquí la cosa es interessant, perquè la resposta és una mica divertida.

La manera estàndard de validar una adreça al navegador és el constructor new URL(string). I aquest constructor és dur. Implacable. Si no hi ha protocol — llança un error. new URL("allegro.pl") et retorna simplement un TypeError i punt.

I saps què? Aquest és el comportament correcte. Per a la gran majoria d'aplicacions, exactament això és el que vols. Però en un formulari per acurtar enllaços, on una persona copia l'adreça de la barra del navegador o d'un missatge de algú, aquesta austeritat passa de ser un avantatge a ser un obstacle. De sobte, una eina que ha de estalviar-te temps, et obliga a corregir tu mateix alguna cosa que, evidentment, entén perfectament.

L'esquena d'això són literalment unes quantes línies:

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)
}

Cinc línies. Una dotzena segons menys de fricció, cada dia, per a tothom qui enganxa adreces. Sincerament no sé per què això no és un estàndard a tot arreu. Suspeito que es tracta de que "així simplement funciona el constructor d'URL" i a ningú no li va donar la gana de tocar-ho. Inèrcia, no mala voluntat.

Una petita digressió sobre què significa "estàndard"

Aquesta història amb new URL() és un gran exemple de sesuatu més ampli. Moltes coses que en el desenvolupament de programari es consideren com a "així és com es fa", són en realitat "així ha resultat de la configuració per defecte de alguna biblioteca que ningú va qüestionar". El mode estricte del constructor no és una decisió dels dissenyadors de cutty ni de la competència — és una decisió dels autors de l'especificació URL, presa en un context completament diferent, per a usos completament diferents.

I després tot el mercat hereta aquesta elecció per defecte i la anomena "estàndard". Tinc la sensació que els millors productes neixen exactament en aquells llocs on algú s'ha aturat i s'ha preguntat: un moment, aquest comportament serveix al meu usuari o només a la meva biblioteca? La majoria de vegades la resposta és: a la biblioteca. I llavors val la pena, amb cinc línies, passar al costat de la persona.

Aquests detalls són més dels que semblen

---

L'Auto-prefix és només un dels molts elements que no trobaràs en cap llista de funcions. Perquè si s'hi incloessin, cada un d'ells semblaria ridicolment petit:

• poda d'espais abans de la validació, perquè un espai accidental al final de l'adreça enganxada no ho estropi tot
• manteniment de l'ancora, és a dir, #section en https://example.com/page#section no desapareix després d'encurtir
• els paràmetre de consulta (?utm_source=test) passen completament, res no es talla pel camí
• dominis amb caràcters polonès, źdźbło.pl, es converteixen automàticament a punycode
• lletres polonès en el final propi es converteixen a ASCII (różowy-link passa a ser rozowy-link)
• protocols perillosos — javascript:, data:, file: — rebujats amb un missatge específic i comprensible

(Ainda es planeja la redirecció automàtica de http:// a https://, quan el servidor de destí suporti el xifratge. Això exactament encara no funciona en directe, així que no faré amaga.)

Cada un d'aquests detalls estalvia a algú cinc, deu, trenta segons i un suspir. Per separat, res. Junts, és la diferència entre "funciona OK" i "m'agrada utilitzar-ho".

Què m'agradaria fer encara més

Llista de desitjos per al futur, perquè pensar-hi simplement m'aporta alegria:

• enganxat intel·ligent — detectar una adreça amagada dins d'una frase i extreure només la URL entre les paraules
• enganxat massiu — una llista d'adreces, una per línia, i de cada una un enllaç curt separat immediatament
• suggeriments de finalització — proposar tres slugs de marca a triar basant-se en el títol de la pàgina de destí
• previsualització Open Graph immediatament després d'enganxar, abans de fer clic a "acurtar"

Cada una d'aquestes és de nou una "funció de cinc línies que no sembla res". I totes juntes? És precisament aquest límit entre una eina que està bé i una a la qual recorres cada dia sense pensar-ho. Si vols veure com funciona ara mateix, enganxa a cutty.dev qualsevol cosa sense protocol — allegro.pl, github.com, news.ycombinator.com — i comprova que no et posa cap obstacle al camí.

Al final, una mica personalment

He pensat durant molt de temps que els productes guanyaven amb grans funcions. Amb aquella cosa espectacular única que es pot mostrar en una diapositiva i sobre la qual la gent escriure. I sí, a vegades és així.

Però, com més temps passo construint cutty, més fort sento que la fidelitat de l'usuari neix en un altre lloc — en aquestes centenars de microsegons que ningú nota conscientment. No recordes que l'eina va afegir per si mateixa el https://. Només recordes la impressió general de que "de alguna manera es fa bé servir", "no molesta". Aquesta impressió no apareix de la nada. Es compon de desenes de decisions de cinc línies que, individualment, ningú defensaria davant de si mateix com a "mereixen el temps".

Potser de això tracta l'artesa. No d'un sol gran moviment, sinó de la persistència de posar-se un cop i altre al costat de l'usuari davant del formulari — encara que es tracti de dues pobres segons. I tu? Què t'ha molestat últimament en alguna eina de forma tan mínima que fins fa vergonya admetre-ho? Perquè normalment és precisament allà on resideix la millor feina per fer.