No meu projeto eu utilizei a template string ao invés de criar uma váriavel para mensagem e funcionou do mesmo jeito, o HTML funcionou da mesma forma. Porém não entedi se isso é algo errado de se fazer, alguém poderia tirar essa dúvida para mim?
No meu projeto eu utilizei a template string ao invés de criar uma váriavel para mensagem e funcionou do mesmo jeito, o HTML funcionou da mesma forma. Porém não entedi se isso é algo errado de se fazer, alguém poderia tirar essa dúvida para mim?
Olá Gustavo,
Não é algo errado de se fazer, é apenas uma alternativa. As template strings são um atalho para concatenação de strings.
No geral, quando pensamos em "algo errado de se fazer" na programação, devemos refletir se o que estamos fazendo impacta na lógica, no desempenho, ou na legibilidade do nosso código.
Substituir a variável por uma template string não altera nem a lógica e nem o desempenho de forma significativa. E em termos de legibilidade, vai depender do caso.
Ou seja, não se preocupe, existem sempre várias maneiras de alcançar o mesmo resultado programando, e o que torna algumas melhores que outras são os aspectos acima, basicamente.
Se tiver dúvidas posteriores similares a essa, pode sempre checar alguns guias de boas práticas (neste caso em JavaScript, mas existem guias para todas as linguagens): https://code.tutsplus.com/pt/24-javascript-best-practices-for-beginners--net-5399t, e também em: https://www.devmedia.com.br/boas-praticas-de-programacao-em-javascript/34215.
Fiquei com a mesma dúvida e fui pesquisar. Vai ser um problema apenas em navegadores mais antigos. Se quiser tornar seu código compatível com mais máquinas, não utilize template literal (template string), crie uma variável conforme demonstrado.
Lista de navegadores que suportam e não suportam template literal: https://caniuse.com/template-literals
Realmente, isso é um ponto válido. Entretanto, estudando o suporte a esse recurso com mais profundidade, fica claro que a porcentagem de usuários que utilizam navegadores sem suporte é inferior a 5%, e portanto, caem na margem de perda de acessos esperada.
Observe os dados atualizados do uso de navegadores fornecido em 2023 pelo StatCounter: https://gs.statcounter.com. Os usuários de Chrome, Safari, Edge, Firefox, Opera, e Samsung Internet correspondem, juntos, a 97.07% dos usuários ativos.
Todos esses navegadores possuem suporte a esse recurso desde 2016 no máximo (alguns desde 2014-2015). E as versões sem suporte desses browsers correspondem a apenas 0.12% dos usuários globais, segundo a fonte que você citou: https://caniuse.com/template-literals.
Dessa forma, de maneira aproximada, 96.95% dos usuários não terão a experiência de uso do website ou webapp afetada pela falta de compatibilidade com esse recurso. E com isso, os benefícios internos ao desenvolvimento superam o malefício da perda de acessos, e utilizar recursos de compatibilidade tão próxima de 100% é mais do que seguro.
Lembrando sempre que, com exceção do padrão ECMAScript 2000, nenhum outro recurso de linguagem é 100% compatível com todas as engines da linguagem, e portanto, se nos prendermos à necessidade de uma compatibilidade completa, uma enorme quantidade de recursos importantes terá de ser descartada. Veja o médoto "Object.values", que é reconhecidamente importante: apenas 97.56% de compatibilidade com os browsers atuais. E mesmo assim não possui nenhuma restrição de uso.
A compatibilidade deve ser levada de forma secundária na seleção dos recursos a serem usados em uma aplicação, especialmente quando encrontramos polyfills para o tal recurso. E, especialmente em um ambiente de aprendizagem, os benefícios de um código claro e legível superam, e muito, qualquer pequena perda de acessos por incompatibilidade.
No caso, estou apenas indicando o uso conforme os próprios instrutores demonstraram. Eles é que estão prezando pela maior compatibilidade ao criar uma variável apenas para armazenar o template literal. No meu código estou passando diretamente pela função; como você disse, fica mesmo mais legível. :-)