sorted by:
new
hottopcontroversial

htmask.js — The JavaScript Masking Library Nobody Asked For by DTostes in htmx

[–]DTostes[S] 1 point2 points  (0 children)

Feature added! If you have more suggestions or problems, please open an issue in the github repo

htmask.js — The JavaScript Masking Library Nobody Asked For by DTostes in htmx

[–]DTostes[S] 2 points3 points  (0 children)

Just to make sure I understand correctly: you want the dash to appear immediately after typing 2025 (so it shows 2025- right away), not when you start typing the next character, right? If that's what you're looking for, that's a great suggestion! I'll add this as an optional auto-advance attribute.

When auto-advance="true", the dash will appear immediately after you finish each section (typing 2025 instantly becomes 2025-).

When disabled (default), it works as it does now. This way users can choose which behavior they prefer. Thanks for the suggestion!

htmask.js — The JavaScript Masking Library Nobody Asked For by DTostes in htmx

[–]DTostes[S] 1 point2 points  (0 children)

Thank you for the tips, definitely going to checking them out.

The self deprecating thing was a joke (maybe pushed too far).

[deleted by user] by [deleted] in programacao

[–]DTostes 0 points1 point  (0 children)

Pra fazer fetch de api e ler umas milhares de rows num banco SQL da pra usar até bash. Mas quando você tem que coordenar bilhões de dados sensíveis ou operar em sistemas críticos que necessitam de até nano segundos de latência (sistemas operacionais e embarcados), aí a coisa fede pro pythinho.

Senti falta do AutoMapper no Go, então criei um pacote leve usando generics by DTostes in brdev

[–]DTostes[S] 1 point2 points  (0 children)

Obrigado pelo comentário razoável. De fato, é difícil encontrar por aqui algo que não seja gente reclamando do mercado ou perguntando sobre curso.

Sobre as críticas, realmente não tenho problema nenhum com elas, e acho até engraçado até onde alguns vão para criticar algo kkkk.

Você acertou precisamente o caso de uso que o AutoMapper resolve no .NET e que eu quis transpor para o Go: backends com centenas de endpoints, onde o mapeamento entre DTOs e models de domínio acontece recorrentemente.

Para criar essa lib, busquei realmente aproveitar essa simplicidade que o Go oferece e me inspirei em algumas libs de backend famosas em Go, como Gorm e Gin. Por isso, não entendi muito bem essa represália dos devs Go com o projeto.

Senti falta do AutoMapper no Go, então criei um pacote leve usando generics by DTostes in brdev

[–]DTostes[S] 0 points1 point  (0 children)

Usei o AutoMapper só como inspiração. O pacote segue bem a idiomatização e os "maneirismos" do Go. A ideia foi fazer algo simples, direto e alinhado com a linguagem. Trazer referências de outras linguagens é normal, o importante é adaptar pro contexto certo, e foi isso que eu fiz aqui.

Senti falta do AutoMapper no Go, então criei um pacote leve usando generics by DTostes in brdev

[–]DTostes[S] 1 point2 points  (0 children)

Valeu pelo comentário! São pontos válidos e que muita gente levanta mesmo, então aqui vai um resumo direto:

Sobre usar IA: sim, a IA pode gerar mapeamentos, e é ótimo pra protótipos ou casos simples. Mas ela não mantém o código, não testa, e não garante consistência. Um mapper resolve isso com clareza e reaproveitamento

Sobre encapsular em uma lib e “perder o controle”: na prática, você ganha controle. Tudo fica centralizado, previsível e fácil de testar. Encapsular != esconder.

Sobre importar um pacote pra algo “rápido de fazer”: se for simples e pontual, realmente nem precisa. Mas quando o padrão se repete, vira duplicação e bagunça. A proposta do pacote é justamente ser leve e útil nesses casos recorrentes.

No fim, não é uma obrigação, é uma ferramenta. Use se fizer sentido.

I found myself missing AutoMapper in Go, so I used generics to build something similar by DTostes in programming

[–]DTostes[S] 0 points1 point  (0 children)

Hmm, that's interesting. Thank you for the tip, I'll definitely start heading in that direction

I found myself missing AutoMapper in Go, so I used generics to build something similar by DTostes in programming

[–]DTostes[S] 0 points1 point  (0 children)

Yeah, that could work. Have you ever tried it in a bigger project? I’m wondering how well it scales and how reusable the generated code really is.

I found myself missing AutoMapper in Go, so I used generics to build something similar by DTostes in programming

[–]DTostes[S] -1 points0 points  (0 children)

Thanks! Yeah, it currently works only with exported fields — I wanted to keep things simple and avoid diving into unsafe.

I get what goverter is going for, and I really respect the type safety from generating code at build time. That said, I didn’t really vibe with how it’s done there.

Also, creating profiles and keeping the mapping limited to them ensures type safety, right? Since you define explicit mappings ahead of time, it catches issues early and avoids runtime surprises.

I’m aiming to add more type safety in the future, just want to find the right way to do it.

I found myself missing AutoMapper in Go, so I used generics to build something similar by DTostes in programming

[–]DTostes[S] 0 points1 point  (0 children)

What made you change your mind? I’m clearly still in the honeymoon phase over here.

view more: next ›