Auto-prefix URL — um detalhe que poupa minutos
cutty.dev reconhece quando você cola um endereço sem https:// e o adiciona automaticamente. Parece algo trivial. Na prática, é a diferença entre dois segundos ou ter que clicar em 'tentar novamente'.
Você digita no formulário allegro.pl. Você clica. E então?
Na maioria dos encurtadores, você recebe uma mensagem de erro neste momento. Algo como "este não é um URL válido". Porque não há https:// no início. Então você volta, adiciona o protocolo, clica novamente e só agora você tem o seu link curto.
cutty.dev não faz isso. Ele simplesmente anexa https:// e segue em frente, como se nada tivesse acontecido.
Eu sei como isso soa. Como um recurso que mal merece um parágrafo, quanto mais uma postagem inteira. No entanto, estou aqui escrevendo sobre isso porque este pequeno detalhe é, para mim, um pequeno manifesto de como eu penso sobre a construção da ferramenta auto-prefix URL e todo o resto dessas facilidades invisíveis.
Dois segundos contra vinte
Vamos fazer as contas. De verdade, com números, porque do contrário é apenas conversa.
Primeiro caminho: você cola, tem o link, fecha a janela. Dois segundos. Talvez três.
Segundo caminho: você cola, erro, lê a mensagem (um segundo ou dois para entender o que está acontecendo), adiciona o protocolo, clica novamente, só agora o link. Quinze, vinte segundos. Mais aquele pequeno momento de irritação, aquele silencioso "ah é mesmo, o protocolo", que não custa nada individualmente, mas vai se acumulando.
Agora multiplique isso pelo número de vezes que você cola algum endereço por mês. Para mim, são dezenas. Para alguém que gerencia links profissionalmente — centenas. De repente, esse detalhe "mal digno de menção" acumula-se em minutos por mês. Por pessoa.
Esta é precisamente a aritmética que a maioria das pessoas ignora, porque cada caso individual parece pequeno demais para se preocupar com ele.
O que exatamente está acontecendo por baixo
O mecanismo é banal e eu não escondo isso de forma alguma. Você cola o texto no campo. Antes que qualquer coisa seja enviada para o servidor, um pedaço de JavaScript verifica se o que você digitou começa com algum protocolo — http://, https://, ftp://, mailto:, o que for. Se não começar, o sistema assume que você tem em mente um domínio comum e anexa https:// na frente.
Na prática:
allegro.pltransforma-se emhttps://allegro.plgithub.com/twoj-profil/projektemhttps://github.com/twoj-profil/projektwww.gazeta.plemhttps://www.gazeta.pl
E se o protocolo já estiver lá, mesmo que seja estranho, o sistema não o sobrescreve. Ele o mantém e continua verificando o que fazer com isso. http://example.com passa (permitido). ftp://example.com vai para o lixo, pois aceitamos apenas http e https. E javascript:alert(1) é descartado imediatamente, porque isso não é um endereço, é uma tentativa de injetar algo malicioso (XSS clássico, obrigado, mas não).
Por que eu tenho isso e metade do mercado não
Aqui as coisas ficam interessantes, porque a resposta é um pouco engraçada.
A forma padrão de validar um endereço no navegador é o construtor new URL(string). E este construtor é rígido. Sem compromissos. Não há protocolo — ele lança um erro. new URL("allegro.pl") simplesmente retorna um TypeError e pronto.
E sabe de uma coisa? Este é o comportamento correto. Para a grande maioria das aplicações, é exatamente isso que você deseja. Mas em um formulário para encurtar links, onde uma pessoa copia o endereço da barra do navegador ou de uma mensagem de alguém, essa crueza deixa de ser uma vantagem e se torna um obstáculo. De repente, uma ferramenta que deveria lhe poupar tempo exige que você corrija algo que, na verdade, ela compreende perfeitamente.
A solução para isto é literalmente algumas linhas:
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)
}
Cinco linhas. Algumas dezenas de segundos a menos de atrito, por dia, para cada pessoa que cola endereços. Sinceramente, não sei por que isso não é o padrão em todo lugar. Suspeito que seja porque "o construtor de URL simplesmente funciona assim" e ninguém quis mexer nisso. Inércia, não má vontade.
Uma pequena digressão sobre o que significa "normalmente"
Porque essa história com new URL() é um ótimo exemplo de algo mais amplo. Muitas coisas que no desenvolvimento de software são consideradas "é assim que se faz", são na verdade "foi assim que resultou das configurações padrão de alguma biblioteca que ninguém questionou". O modo estrito do construtor não é uma decisão dos designers da cutty nem da concorrência — é uma decisão dos autores da especificação URL, tomada em um contexto completamente diferente, para aplicações completamente diferentes.
E depois todo o mercado herda essa escolha padrão e a chama de "padrão". Tenho a impressão de que os melhores produtos nascem exatamente nesses lugares onde alguém parou e perguntou: espera, este comportamento serve ao meu usuário ou apenas à minha biblioteca? Na maioria das vezes, a resposta é: à biblioteca. E então vale a pena usar cinco linhas para mudar o foco para o ser humano.
Há mais destes detalhes do que se vê
Auto-prefix é apenas um dos muitos elementos que você não encontrará em nenhuma lista de recursos. Porque se eles fossem listados lá, cada um individualmente pareceria ridiculamente pequeno:
- remoção de espaços antes da validação, para que um espaço acidental no final do endereço colado não estrague tudo
- preservação da âncora, ou seja,
#sectionemhttps://example.com/page#sectionnão desaparece após o encurtamento - parâmetros de consulta (
?utm_source=test) passam integralmente, nada é cortado no caminho - domínios com caracteres poloneses,
źdźbło.pl, são convertidos automaticamente para punycode - letras polonesas no próprio slug são substituídas por ASCII (
różowy-linktorna-serozowy-link) - protocolos perigosos —
javascript:,data:,file:— são rejeitados com uma mensagem específica e compreensível
(Ainda está planejado o upgrade automático de http:// para https:// quando o servidor de destino suportar criptografia. Isso ainda não funciona ao vivo, então não vou fingir.)
Cada um desses detalhes economiza a alguém cinco, dez, trinta segundos e um suspiro. Individualmente, nada. Juntos, é a diferença entre "funciona OK" e "gosto de usar isso".
O que eu gostaria de ganhar extra
Lista de desejos para o futuro, porque pensar nisso simplesmente me dá prazer:
- colagem inteligente — detectar um endereço escondido no meio de uma frase e extrair apenas a URL entre as palavras
- colagem em massa — lista de endereços, um por linha, e gera imediatamente um link curto separado para cada um
- sufixos sugeridos — com base no título da página de destino, propor três slugs de marca para escolha
- visualização Open Graph imediatamente após colar, antes mesmo de clicar em "encurtar"
Cada uma disso é novamente uma "função de cinco linhas que não parece nada". E todas juntas? É exatamente essa a fronteira entre uma ferramenta que é aceitável e aquela que você usa todos os dias sem pensar. Se quiser ver como isso funciona agora, cole no cutty.dev qualquer coisa sem protocolo — allegro.pl, github.com, news.ycombinator.com — e veja que nada te coloca obstáculos no caminho.
Por fim, um pouco pessoalmente
Pensei durante muito tempo que os produtos venciam com grandes funcionalidades. Aquela única coisa impressionante que pode ser mostrada num slide e sobre a qual as pessoas escreverão. E sim, às vezes é assim.
Quanto mais tempo construo cutties, mais forte sinto que a lealdade do usuário nasce em outro lugar — naquelas centenas de microssegundos que ninguém percebe conscientemente. Você não se lembra que a ferramenta adicionou https:// por conta própria. Você apenas lembra da impressão geral de que "é bom de usar" ou "não irrita". Essa impressão não surge do nada. Ela é composta por dezenas de decisões de cinco linhas que, individualmente, ninguém defenderia como "valendo o tempo".
Talvez seja exatamente disso que consiste o artesanato. Não naquele único grande movimento, mas na persistência de estar, vez após vez, ao lado do ser humano ao preencher um formulário — mesmo que se trate de meros dois segundos. E você? O que te irritou ultimamente em alguma ferramenta de forma tão pequena que chega a dar vergonha de admitir? Porque geralmente é exatamente aí que reside o melhor trabalho a ser feito.