Você está trabalhando em um projeto com Angular. Você precisa singularizar ou pluralizar dinamicamente suas palavras dependendo de uma contagem para exibir ao usuário final. Uma primeira e comum solução seria pensar e usar i18nPlural .

Por que não usar o i18nPlural o tempo todo?

Pode ser um pouco sobrecarregado para um uso simples. Por exemplo, se você não precisa de nenhuma tradução e precisa apenas pluralizar palavras comuns do idioma, o i18nplural adicionará ao seu projeto tantos recursos extras que você não precisa. Isso pode resultar em um aumento potencial de sua compilação final , por nada, em seu caso de uso. É por isso que pode ser interessante encontrar uma solução mais simples.

Então, que outra solução posso implementar?

Eu pessoalmente escolhi procurar o tubo mais limpo e simples que poderia criar para o meu caso de uso. Portanto, procurei algumas soluções propostas no StackOverflow, para ter uma primeira base. Eu finalmente baseei meu próprio pipe no seguinte código (fonte disponível na última seção):

No entanto, mesmo esse código-fonte ainda era muito complicado para mim. O idioma do meu projeto é o francês. Isso significa que , na maioria das vezes, uma palavra no plural terá um “s” ou um “x” e pronto. Então refatorei em um pipe mais limpo, reduzi pela metade o número de linhas:

Depois que o pipe estiver configurado corretamente, aqui está um exemplo de como usá-lo:

Em conclusão, ele faz o mesmo resultado que o i18nPlural ou o código base faria para mim, mas em um tamanho de arquivo menor, código mais legível e, portanto, mais fácil de manter.

Espera, mas tem alguns casos que não vão funcionar…

De fato, mesmo em francês, para algumas palavras, esse cachimbo não cobrirá o caso. Por exemplo, cheval => chevaux. O código atual apenas adiciona o parâmetro pluralForm no final da palavra, onde para esse exemplo, teríamos que mudar a string existente.

No entanto, o objetivo deste artigo foi mostrar que pode ser uma boa ideia começar o mais próximo possível do seu caso de uso específico . Se chegar um momento em que você precisa adicionar mais casos de uso, isso significa que chegou a hora de refatorar o código. Mas não antes!

Esta afirmação é verdadeira mesmo em uma escala maior. Não desenvolva um recurso extra que seu cliente não peça . Ou pelo menos não antes que seu cliente aceite. Você manterá um código limpo, aumentará a legibilidade do código e até salvará alguns tamanhos de arquivo . É um fato que o desempenho desempenha um grande papel no mundo de hoje, portanto, coloque as probabilidades a seu favor o máximo possível!

Fonte

Postagem StackOverflow usada para meu código base