Stai lavorando a un progetto con Angular. Devi singolarizzare o pluralizzare dinamicamente le tue parole a seconda di un conteggio da mostrare all'utente finale. Una prima e comune soluzione sarebbe pensare e utilizzare i18nPlural .

Perché non usare i18nPlural tutto il tempo?

Può essere un po' sovraccarico per un semplice utilizzo. Ad esempio, se non hai bisogno di alcuna traduzione e hai solo bisogno di pluralizzare parole comuni della lingua, i18nplural aggiungerà al tuo progetto così tante funzionalità extra che non ti servono. Può comportare un potenziale aumento della tua build finale , per niente, nel tuo caso d'uso. Ecco perché può essere interessante trovare una soluzione più semplice.

Quindi, quale altra soluzione posso implementare?

Personalmente ho scelto di cercare la pipa più pulita e semplice che potessi creare per il mio caso d'uso. Pertanto, ho cercato alcune soluzioni proposte su StackOverflow, per avere una prima base. Alla fine ho basato la mia pipa sul seguente codice (fonte disponibile nell'ultima sezione):

Tuttavia, anche questo codice sorgente era ancora troppo complicato per me. La lingua per il mio progetto è il francese. Ciò significa che la maggior parte delle volte una parola pluralizzata avrà una "s" o una "x" e basta. Quindi l'ho rifattorizzato in un tubo più pulito, ridotto della metà del numero di righe:

Una volta che la pipa è stata configurata correttamente, ecco un esempio di come usarla:

In conclusione, fa lo stesso risultato di i18nPlural o del codice base che farebbe per me, ma in un file di dimensioni inferiori, codice più leggibile e quindi più facile da mantenere.

Aspetta, ma ci sono alcuni casi che non funzioneranno...

In effetti, anche in francese, per alcune parole, questa pipa non coprirà il loro caso. Ad esempio, cheval => chevaux. Il codice corrente aggiunge solo il parametro pluralForm alla fine della parola, dove per quell'esempio dovremmo cambiare la stringa esistente.

Tuttavia, lo scopo di questo articolo era mostrare che può essere una buona idea iniziare il più vicino possibile al tuo caso d'uso specifico . Se arriva un momento in cui è necessario aggiungere più casi d'uso, significa che è giunto il momento di refactoring del codice. Ma non prima!

Questa affermazione è vera anche su scala più ampia. Non sviluppare una funzionalità extra che il tuo cliente non richiede . O almeno non prima che il tuo cliente lo accetti. Manterrai un codice pulito, aumenterai la leggibilità del tuo codice e salverai anche alcune dimensioni di file . È un dato di fatto che le prestazioni giocano un ruolo importante nel mondo di oggi, quindi accumula le probabilità a tuo favore il più possibile!

Fonte

Post StackOverflow utilizzato per il mio codice di base