Auto-prefix URL — apróság, amely perceket spórol meg

Beírod az allegro.pl formátumba. Kattintasz. És mi lesz?

A legtöbb rövidítőnál ebben a pillanatban egy hibaüzenet jelenik meg. Valami olyasmi, mint hogy "ez nem egy érvényes URL". Mert nincs benne az elején a https://. Tehát visszamész, hozzáadod a protokollot, rákattintasz újra, és csak most lesz meg a rövidített linked.

cutty.dev ezt nem teszi meg. Csak egyszerűen hozzáilleszteti a https://-t, és folytatja útján, mintha semmi sem lenne.

Tudom, 어떻게 ez hangzik. Olyan funkcióként, amely alig érdemel egy bekezdést, ergo egy egész bejegyzést sem. Mégis itt ülni és erről írni, mert éppen ez az apróság számomra egy kis manifesztuma annak, hogyan gondolkodom egyáltalán az auto-prefix URL eszköz felépítéséről és az összes többi láthatatlan könnyítésről.

Két másodperc kontra húsz

Számoljunk. Valóban, a számokkal, mert különben ez csak pletyka.

Első út: beilleszted, megvan a link, bezárod a ablak. Két másodperc. Talán három.

Második út: bemásolod, hiba, elolvasod az üzenetet (egy-két másodperc, hogy megértsd, miről van szó), hozzáadod a protokollot, még egyszer rákattintasz, és csak most a link. Tizenöt, húsz másodperc. Plusz az a kismall irritáció pillanata, az a halk „ah, igazán, protokoll”, ami egyedileg semmit nem áraz, de felhalmozódik.

Most pedig szorozd meg azzal, hogy havonta hányszor másolsz be egy adott címet. Én tucsinyszereket. Aki profi linkkezelő, az százakat. Hirtelen ez a „szinte jelentéktelen” apróság havonta percekbe rakódik össze. Egyénenként.

Ez pont az az aritmetika, amelyet a legtöbb ember figyelmen kívül hagy, mert minden egyes eset túl kicsinek tűnik ahhoz, hogy aggódjunk érte.

Mi van valójában ott alatta

A mechanizmus nevetséges, és ezt egyáltalán nem rejtegetem. Beilleszted a szöveget a mezőbe. Mielőtt bármi elindulna a szerverre, egy darab JavaScript ellenőrzi, hogy amit beírtál, kezdődik-e valamilyen protokollal — http://, https://, ftp://, mailto:, bármivel. Ha nem úgy kezdődik, a rendszer feltételezi, hogy egy egyszerű doménre gondolsz, és hozzácsatolja az https:// részt az elejére.

A gyakorlatban:

• allegro.pl átalakul https://allegro.pl-lá
• github.com/twoj-profil/projekt https://github.com/twoj-profil/projekt-vé
• www.gazeta.pl https://www.gazeta.pl-lá

És ha a protokoll már ott van, még ha furcsa is, a rendszer nem ír felé. Meghagyja és tovább vizsgálja, mit kezdjen vele. Az http://example.com átmegy (engedélyezett). A ftp://example.com a szemétkosárba kerül, mert csak az http és https protokollokat fogadjuk elfogadni. Az javascript:alert(1) pedig azonnal k 나가, mert ez nem egy cím, hanem egy kellemetlen dolog befúrási kísérlete (klasszikus XSS, köszönjük, nem).

Miért nekem van ez, míg a piac felének nincs

Itt válik izgalmassá, mert a válasz kicsit vicces.

A böngészőben alkalmazott cím-validáció standard módja az new URL(string) konstruktor. És ez a konstruktor kemény. Kompromisszumok nélküli. Nincs benne protokoll — hibát dob. A new URL("allegro.pl") egyszerűen csak egy TypeError-t ad vissza, és ennyi.

És tudod mit? Ez a helyes viselkedés. Az alkalmazások túlnyomlagoló többségének pontosan ezt akarja. De egy linkrövidítő űrlapnál, ahol az ember a böngészősávból vagy valaki üzenetéből másolja ki a címet, ez a szigorúság az előnyből akadály 되어. Hirtelen egy olyan eszköz, aminek időt kellene spórolnia neked, arra kényszerít, hogy javíts valamit, amit egyébként tökéletesen megért.

Ennek megkerülése szó szerint csak néhány sor:

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

Öt sor. Több tucat másodperc kevesebb súrlódás naponta mindenkinek, aki címeket másol be. Komolyan nem tudom, miért nincs ez az alapvető mindenhol. Azt sejtitek, hogy azért van, mert a "URL konstruktor egyszerűen így működik", és senkit sem elég volt hozzáérni hozzá. Inertia, nem rossz szándék.

Kis digresszió arról, mit jelent „standardosan”

Mert ez a new URL() történet egy remek példája valami szélesebbnek. Rengeteg dolog a szoftverfejlesztésben azért számít "úgy csináljuk így", mert valójában "úgy jött ki az egy adott könyvtár alapértelmezett beállításaiból, amit senki nem kérdőjelezett meg". A konstruktor strict mode-ja nem a cutty tervezői vagy a konkurencia döntése — ez az URL specifikáció szerzőinek döntése, amelyet egy teljesen más kontextusban, teljesen más célokra hoztak létre.

Aztán az egész piac örökli ezt a gyári választást, és "sztendárdként" nevezi. Úgy érzem, hogy a legjobb termékek pontosan ott születnek meg, ahol valaki megállت és megkérdezi: egy pillanat, ez a viselkedés valóban a felhasználómnak szolgál, vagy csak az én könyvtáramnak? Leggyakrabban a válasz az, hogy: a könyvtárnak. És ilyenkor érdemes öt sorral az ember oldalára állni.

Ezek az apróságok többek, mint amit látni

Az Auto-prefix csak az egyik számos olyan elem közül, amelyeket nem találsz semmilyen funkciólistán. Mert ha őket odaírnák, minden egyesük viccesen kicsinek tűnne:

• szóközök eltávolítása a validáció előtt, hogy egy véletlen szóköz a beillesztett cím végén ne rontsa el az egészet
• az anchor megőrzése, azaz a #section nem tűnik el a https://example.com/page#section URL-ből a rövidítés után
• a query paraméterek (?utm_source=test) teljes egészében tovább mennek, semmi nem vágódik le útközben
• speciális karakteres domainok, źdźbło.pl, automatikusan punycode formátumra alakulnak
• magyar (vagy lengyel) ékezetes karakterek a saját slug végén ASCII-re cserélődnek (różowy-link válik rozowy-link-é)
• veszélyes protokollok — javascript:, data:, file: — elutasítás egy konkrét, érthető üzenettel

(Még tervezünk automatikus átalakítást az http://-ról https://-re, amennyiben a cél szerver támogatja a titkosítást. Ez éppen még nem működik élőben, így nem fogom úgy tesztelni, mintha működne.)

Minden egyes részlet spórol meg valakinek öt, tíz, harminc másodpercet és egy sóhajt. Egyedül semmit nem. Együtt azonban ez a különbség az "oké, működik" és az "szeretem használni" között.

Mit szeretnék még kiegészíteni

A jövőbeli vágyaim listája, mert egyszerűen csak örömet okoz nekem ezen gondolkodni:

• okos beillesztés — felismerni a mondat közepében rejtett címet, és kinyerni magát az URL-t a szavak közül
• tömeges beillesztés — címek listája, soronként egyetlen, és minden egyesből azonnal külön rövidített link
• javasolt végződések — a céloldal címe alapján három választási lehetőséget kínáló prémium slug

Mindegyik ennek újra egy „öt soros függvény, ami semmit nem jelent”. És mind együtt? Ez pont az a határ egy olyan eszköz között, amely rendben van, és az olyan, amelyhez naponta gondolkodás nélkül nyúlsz. Ha látni szeretnéd, hogyan működik most, másolj be a cutty.dev oldalra bármit protokoll nélkül — allegro.pl, github.com, news.ycombinator.com — és lásd, hogy semmi nem akadályoz meg.

Végezetül, egy kicsit személyesen

Hosszú ideig azt hittem, hogy a termékek a nagyszerű funkciókkal nyernek. Azzal az egyetlen látványos dologgal, ami megmutatható egy diaon, és amiről az emberek írni fognak. És igen, néha ez így van.

Minél tovább építem a cutty-kat, annál erősebben érzem, hogy a felhasználói lojalitás máshol születik — ezekben a százalékos törp másodpercekben, amelyeket senki sem vesz tudatosan észre. Nem emlékszel rá, hogy az eszköz magától hozzáadta neked a https://-t. Csak az általános benyomat marad, hogy "valahogy jól használható", "nem idegesít". Ez a benyomat nem áradt váratlanul. F десятки öttávolas döntésből áll, amelyek közül egyetlenet sem védene meg senki önmagam előtt úgy, hogy "érdemes lenne rá az idő".

Talán pont ebben áll a mesterség. Nem egyetlen nagy lépésben, hanem abban az elszántságban, hogy egymás után az ember oldalán álljunk az űrlapon — még ha erről csak két sínnyel is szó van. És te? Mi az, ami legutóbbi esetben olyan apró volt egy eszköznél, hogy szégyen is bevallani, ami felidegtört? Mert általában éppen ott rejlik a legjobb feladat elvégzendő.