Io non credo che ci sia qualcosa di sbagliato con esso. La sintassi è un po 'funky, ma è un trucco intelligente.
Vorrei mettere in discussione la necessità di una variabile veramente privata. Posso solo pensare a due motivi per cui qualcuno potrebbe volerne uno, ma entrambi possono essere smentiti.
1) Si crea una libreria da consumare da altri ... Se qualcuno sta cercando all'interno del codice della biblioteca dove non dovrebbero essere, il loro o rompe la propria esperienza o aggira bug che ha trovato in il tuo codice. In ogni caso, nessun danno a te o agli altri. Caso peggiore, rompono la loro app. Le variabili private mi hanno lasciato davvero un brutto sapore in bocca. L'apertura di JavaScript è una boccata d'aria fresca IMO.
2) Si desidera nascondere i dati privati all'interno della propria app ... Con i browser moderni, qualsiasi cosa in JavaScript può essere ispezionata e modificata in fase di esecuzione. È impossibile nascondere i dati dagli utenti in JavaScript. Puoi solo rendere le cose difficili da trovare.
So che questa alternativa non è veramente privata, ma l'utilizzo è lo stesso. Dal momento che non sono un grande fan di lottare duramente per rendere le cose private, lo includerò comunque. ; G)
var Hello = React.createClass({
name: null,
getInitialState: function() {
this.name = "Sir " + this.props.name;
return null;
},
render: function() {
return <div>Hello {this.name}</div>;
};
});
React.render(<Hello name="World" />, document.getElementById('container'));
fonte
2015-09-10 03:06:35
Beh, io sono un grande fan delle variabili private, perché qualcuno della mia squadra può provare a utilizzare la variabile per errore e impiegare ore per scoprire che non è stato ipotizzato di essere utilizzato. A volte, se viene utilizzato, il software diventa più lento o un bug impercettibile. In altri linguaggi come Java o C# è molto comune usare variabili private, in realtà io uso più variabili private che variabili pubbliche. – melanke
Capisco. Scrivo molto Java. Tuttavia, non è solo il modo in cui le cose vengono tipicamente fatte in JS. La maggior parte delle volte non mi interessa il funzionamento interno di una biblioteca. Comunque nel raro caso che mi interessi, sto cercando di deridere una libreria mal progettata e le variabili private/anon funzioni mi impediscono di scrivere un buon test unitario o semplicemente di aggirare un bug ... IMO, è come usare metodi "finali" in Java (che nella maggior parte dei framework non sono bloccabili) ... Se ritieni di aver bisogno di dati privati per proteggerti dagli sviluppatori, guarderei i tuoi sviluppatori o la tua libreria, non i principi di codifica. –