Auto-prefix URL — дрібниця, яка економить хвилини

Ви вводите у форму allegro.pl. Натискаєте. І що?

У більшості скорочувачів у цей момент ви отримуєте повідомлення про помилку. Щось на кшталт "це не є правильна URL-адреса". Тому що попереду немає https://. Отже, ви повертаєтеся назад, дописуєте протокол, натискаєте ще раз, і тільки тепер у вас є ваше коротке посилання.

cutty.dev цього не робить. Просто сам додає https:// і йде далі, ніби нічого й не було.

Я знаю, як це звучить. Як фіча, яка ледь заслуговує на абзац, не кажучи вже про цілий допис. І все ж я сиджу і пишу про це, бо саме ця дрібниця є для мене маленьким маніфестом того, як я взагалі думаю про створення інструменту auto-prefix URL та всієї решти цих невидимих полегшень.

Дві секунди проти двадцяти

Порахуймо. Справді, на цифрах, бо інакше це лише балаканина.

Перший шлях: вставляєш, маєш посилання, закриваєш вікно. Дві секунди. Може три.

Другий шлях: вставляєш, помилка, читаєш повідомлення (секунда чи дві, щоб зрозуміти, про що йдеться), дописуєш протокол, клікаєш ще раз, і тільки тепер посилання. П'ятнадцять, двадцять секунд. Плюс цей крихітний момент роздратування, це тихе "а, точно, протокол", яке окремо нічого не коштує, але накопичується.

А тепер помнож на те, скільки разів на місяць ти вставляєш якусь адресу. У мене це десятки. У того, хто керує посиланнями професійно — сотні. Раптом ця «ледь варта згадки» дрібниця перетворюється на хвилини щомісяця. На одну особу.

Це саме та арифметика, яку більшість людей ігнорує, тому що кожен окремий випадок здається занадто малим, щоб ним перейматися.

Що там насправді всередині

Механізм банальний і я зовсім цього не приховую. Ви вставляєте текст у поле. Перш ніж щось надійде на сервер, фрагмент JavaScript перевіряє, чи те, що ви ввели, починається з якогось протоколу — http://, https://, ftp://, mailto:, будь-чого. Якщо не починається, система припускає, що ви маєте на увазі звичайний домен, і додає https:// попереду.

На практиці:

• allegro.pl змінюється на https://allegro.pl
• github.com/twoj-profil/projekt на https://github.com/twoj-profil/projekt
• www.gazeta.pl на https://www.gazeta.pl

А якщо протокол уже там є, навіть якщо він дивний, система його не перезаписує. Залишає і перевіряє далі, що з цим робити. http://example.com проходить (дозволено). ftp://example.com летить у кошик, бо ми приймаємо тільки http та https. А javascript:alert(1) вилітає негайно, бо це не адреса, а спроба впорскнути щось гидке (класичний XSS, дякуємо, ні).

Чому це маю я, а половина ринку — ні

Тут стає цікаво, бо відповідь трохи смішна.

Стандартний спосіб валідації адреси в браузері — це конструктор new URL(string). І цей конструктор жорсткий. Безкомпромісний. Немає протоколу — викидає помилку. new URL("allegro.pl") повертає вам просто TypeError і все.

І знаєш що? Це правильна поведінка. Для величезної більшості додатків саме цього ти й хочеш. Але у формі для скорочення посилань, де людина копіює адресу з адресного рядка браузера або з чийогось повідомлення, ця суворість перетворюється з переваги на перешкоду. Раптом інструмент, який має економити твій час, змушує тебе виправляти за собою те, що він і так чудово розуміє.

Обхід цього — це буквально кілька рядків:

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

П'ять рядків. Кілька секунд менше тертя щодня для кожного, хто вставляє адреси. Щиро не знаю, чому це не є стандартом усюди. Підозрюю, що справа в тому, що «URL-конструктор просто так працює» і нікому не захотілося цього чіпати. Інерція, а не злий намір.

Маленьке відступлення про те, що означає "стандартно"

Бо ця історія з new URL() — чудовий приклад чогось ширшого. Безліч речей у програмному забезпеченні, які вважаються такими, що «так прийнято робити», насправді є результатом того, що «так вийшло з налаштуваннями за замовчуванням якоїсь бібліотеки, яку ніхто не піддавав сумніву». Strict mode конструктора не є рішенням дизайнерів cutty чи конкурентів — це рішення авторів специфікації URL, прийняте в зовсім іншому контексті, для зовсім інших цілей.

А потім увесь ринок успадковує цей вибір за замовчуванням і називає його "стандартом". У мене таке враження, що найкращі продукти народжуються саме в тих місцях, де хтось зупинився і запитав: зачекайте, чи ця саме поведінка служить моєму користувачеві, чи тільки моїй бібліотеці? Найчастіше відповідь звучить так: бібліотеці. І тоді варто п'ятьма рядками перейти на сторону людини.

Цих дрібниць більше, ніж здається

Auto-prefix — це лише один із багатьох таких елементів, яких ви не знайдете в жодному списку функцій. Бо якби їх туди вписали, кожен окремо виглядав би смішно малим:

• обрізання пробілів перед валідацією, щоб випадковий пробіл у кінці вставленої адреси не зіпсував усе
• збереження якоря, тобто #section у https://example.com/page#section не зникає після скорочення
• параметри запиту (?utm_source=test) проходять повністю, нічого не обрізається по дорозі
• домени з польськими символами, źdźbło.pl, автоматично перетворюються на punycode
• польські літери у власному закінченні замінюються на ASCII (różowy-link стає rozowy-link)
• небезпечні протоколи — javascript:, data:, file: — відхиляються з конкретним, зрозумілим повідомленням

(Ще планується автоматичне підсилення http:// до https://, коли цільовий сервер підтримує шифрування. Це саме ще не працює в реальному часі, тому я не буду вдавати.)

Кожна з цих деталей заощаджує комусь п'ять, десять, тридцять секунд і один зітхання. Поодинці — нічого. Разом це різниця між "працює ОК" та "мені подобається цим користуватися".

Що я хотів би ще додати

Список побажань на майбутнє, бо мислення про це просто приносить мені задоволення:

• інтелектуальне вставлення — виявити адресу, приховану всередині речення, і витягнути лише сам URL серед слів
• масове вставлення — список адрес, по одній на рядок, і з кожної одразу окреме коротке посилання
• підказки закінчень — на основі заголовка цільової сторінки запропонувати три брендовані слюги на вибір
• попередній перегляд Open Graph одразу після вставлення, ще до того, як ви натиснете "скоротити"

Кожне з цього знову "п'ятирядкова функція, яка виглядає як ніщо". А всі разом? Це саме та межа між інструментом, який є непоганим, і таким, до якого ти звертаєшся щодня не замислюючись. Якщо хочеш побачити, як це працює зараз, встав у cutty.dev будь-що без протоколу — allegro.pl, github.com, news.ycombinator.com — і побачиш, що ніщо не стає тобі на заваді.

Наприкінці, трохи особистого

Довго я думав, що продукти перемагають великими функціями. Тим одним ефектним чимось, що можна показати на слайді і про що напишуть люди. І так, іноді це саме так.

Але чим довше я будую cutty, тим сильніше відчуваю, що лояльність користувача народжується деінде — у тих сотнях мікросекунд, яких ніхто свідомо не помічає. Ви не пам'ятаєте, що інструмент сам додав вам https://. Ви пам'ятаєте лише загальне враження, що "якось добре цим користуватися", "не дратує". Це враження не береться з нізвідки. Воно складається з десятків п'ятирядкових рішень, які окремо ніхто б не захистив перед собою як такі, що "вартують часу".

Можливо, саме в цьому полягає ремесло. Не в одному великому русі, а в наполегливості, щоб раз по раз ставати на бік людини біля форми — навіть якщо йдеться про жалюгідні дві секунди. А ти? Що тебе останнім часом роздратувало в якомусь інструменті настільки дрібному, що аж соромся зізнатися? Бо зазвичай саме там і ховається найкраща робота, яку варто зробити.