Auto-prefix URL — en liten detalj som sparar minuter

Du skriver in allegro.pl i formuläret. Du klickar. Och vad händer?

I de flesta förkortare får du ett felmeddelande i det här ögonblicket. Något i stil med "detta är inte en giltig URL". Eftersom det saknas https:// längst fram. Så du går tillbaka, lägger till protokollet, klickar igen, och först nu har du din korta länk.

cutty.dev gör inte det. Den bara lägger till https:// och fortsätter som om ingenting hade hänt.

Jag vet hur det låter. Som en funktion som knappt förtjänar ett stycke, än mindre ett helt inlägg. Men ändå sitter jag och skriver om det, eftersom just denna detalj är för mig ett litet manifest över hur jag överhuvudtaget tänker kring byggandet av verktyget auto-prefix URL och resten av dessa osynliga underlättningar.

Två sekunder mot tjugo

Låt oss räkna. Verkligen, med siffror, för annars är det bara prat.

Första vägen: du klistrar in, får en länk, stänger fönstret. Två sekunder. Kanske tre.

Andra vägen: du klistrar in, felmeddelande, läser meddelandet (en sekund eller två för att förstå vad det handlar om), lägger till protokollet, klickar igen, först nu länken. Femton, tjugo sekunder. Plus det där lilla ögonblicket av irritation, det där tysta "just det, protokollet", som inte kostar något enskilt, men som ackumuleras.

Multiplicera nu detta med hur många gånger per månad du klistrar in en adress. För mig är det dussintals. För någon som hanterar länkar professionellt — hundratals. Plötsligt ackumuleras denna "knappt värd att nämna" detalj till minuter per månad. Per person.

Det här är precis den aritmetik som de flesta ignorerar, eftersom varje enskilt fall verkar för litet för att bry sig om.

Vad är det egentligen som finns under huven

Mekanismen är banal och jag döljer inte det alls. Du klistrar in texten i fältet. Innan något skickas till servern kontrollerar en bit JavaScript om det du skrev börjar med något protokoll — http://, https://, ftp://, mailto:, vad som helst. Om det inte börjar så antar systemet att du menar en vanlig domän och lägger till https:// längst fram.

I praktiken:

• allegro.pl ändras till https://allegro.pl
• github.com/twoj-profil/projekt till https://github.com/twoj-profil/projekt
• www.gazeta.pl till https://www.gazeta.pl

Och om protokollet redan finns där, även om det är märkligt, så skriver systemet inte över det. Det lämnar det kvar och fortsätter att kontrollera vad man ska göra med det. http://example.com går igenom (tillåtet). ftp://example.com åker i papperskorgen, eftersom vi endast accepterar http och https. Och javascript:alert(1) kastas ut omedelbart, eftersom det inte är en adress, utan ett försök att injicera något vidrigt (klassisk XSS, tack nej).

Varför har jag detta, medan hälften av marknaden inte har det

Här blir det intressant, eftersom svaret är lite roligt.

Standard sätt att validera en adress i webbläsaren är konstruktorn new URL(string). Och den här konstruktorn är hård. Kompromisslös. Saknas protokollet — så kastar den ett fel. new URL("allegro.pl") ger dig helt enkelt ett TypeError och det är allt.

Och vet du vad? Det är ett korrekt beteende. För den absoluta majoriteten av applikationer är det precis vad du vill ha. Men i ett formulär för att förkorta länkar, där en människa kopierar en adress från webbläsarens adressfält eller från någons meddelande, förvandlas denna stränghet från en fördel till ett hinder. Plötsligt tvingar ett verktyg som är tänkt att spara tid dig att rätta till något som det ändå förstår perfekt.

En lösning på detta är bokstavligen några rader:

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

Fem rader. Ett dussintal sekunder mindre friktion, varje dag, för alla som klistrar in adresser. Jag vet ärligt talat inte varför detta inte är standard överallt. Jag misstänker att det handlar om att "URL-konstruktorn bara fungerar så" och att ingen orkade röra vid det. Tröghet, inte illvilja.

En liten parentes om vad "standardmässigt" betyder

För att den här historien med new URL() är ett utmärkt exempel på något mer omfattande. Massor av saker inom programvara som anses vara "så här gör man" är i själva verket "så blev det på grund av standardinställningarna i något bibliotek som ingen ifrågasatte". Konstruktorns strict mode är inte ett beslut från cutty-designers eller konkurrenter — det är ett beslut från författarna till URL-specifikationen, fattat i ett helt annat sammanhang, för helt andra användningsområden.

Och sedan ärver hela marknaden detta förvalda val och kallar det "standard". Jag får känslan av att de bästa produkterna föds precis på de platser där någon stannade upp och frågade: vänta, tjänar just detta beteende min användare, eller bara mitt bibliotek? Oftast är svaret: biblioteket. Och då är det värt att med fem rader vända sig mot människan.

Det finns fler av dessa småsaker än vad man ser

Auto-prefix är bara ett av många sådana element som du inte hittar på någon lista över funktioner. För om de skrevs där skulle varje enskild se löjligt liten ut:

• trimma mellanslag före validering, så att ett oavsiktligt mellanslag i slutet av en infogad adress inte förstör allt
• behålla ankare, det vill säga #section i https://example.com/page#section försvinner inte efter förkortning
• frågparametrar (?utm_source=test) överförs i sin helhet, inget klipps bort på vägen
• domäner med polska tecken, źdźbło.pl, konverteras automatiskt till punycode
• polska bokstäver i den egna ändelsen ersätts med ASCII (różowy-link blir rozowy-link)
• osäkra protokoll — javascript:, data:, file: — nekas med ett specifikt, begripligt meddelande

(Det planeras även en automatisk uppgradering av http:// till https:// när målservern stöder kryptering. Detta fungerar ännu inte live, så jag kommer inte att låtsas som att det gör det.)

Varje en av dessa detaljer sparar någon fem, tio, trettio sekunder och en suck. Var för sig ingenting. Tillsammans är det skillnaden mellan "det fungerar OK" och "jag gillar att använda det".

Vad jag skulle vilja tjäna extra på

Önskelista för framtiden, eftersom det helt enkelt ger mig glädje att tänka på den:

• intelligent klistring — upptäcka en adress gömd i en mening och extrahera endast URL:en från orden
• massklistring — en lista med adresser, en per rad, och skapa omedelbart en separat kort länk för varje
• föreslagna ändelser — föreslå tre varumärkesspecifika slugs att välja mellan baserat på målsidans titel
• Open Graph-förhandsvisning direkt vid klistring, redan innan du klickar på "förkorta"

Var och en av dessa är återigen en "femradig funktion som inte ser ut för något". Och alla tillsammans? Det är just den gränsen mellan ett verktyg som är okej, och ett som du använder varje dag utan att tänka efter. Om du vill se hur det fungerar nu, klistra in vad som helst utan protokoll i cutty.dev — allegro.pl, github.com, news.ycombinator.com — och se att inget sätter hinder i din väg.

Slutligen, lite personligt

Länge trodde jag att produkter vann med stora funktioner. Med det där enda effektiva som går att visa på en slide och som folk kommer att skriva om. Och ja, ibland är det så.

Men ju längre jag bygger cutty, desto starkare känner jag att användarlojalitet föds någon annanstans — i de där hundratals mikrosekunderna som ingen medvetet lägger märke till. Du kommer inte ihåg att verktyget själv lade till https://. Du kommer bara ihåg det allmänna intrycket att "det är ganska bra att använda", "det är inte irriterande". Det intrycket kommer inte från ingenstans. Det består av dussintals femradiga beslut som ingen enskilt skulle försvara inför sig själv som "värda tiden".

Kanske är det precis det som är hantverket. Inte i den där enda stora rörelsen, utan i envisheten att gång på gång stå på människans sida vid formuläret — även om det bara handlar om två ynkliga sekunder. Och du? Vad har irriterat dig senast med ett verktyg, så lite att det nästan är pinsamt att erkänna? För oftast är det precis där det bästa arbetet väntar på att göras.