crearea componentelor AngularJS foarte reutilizabile
pregătirea aplicației AngularJS pentru Angular
fără îndoială, dacă aveți de gând să construiască o nouă aplicație astăzi s-ar putea începe cu Angular construit pe Typescript (Angular 2+). Cu toate acestea, cu mii de AngularJS (unghiular 1.X) Aplicații încă în producție, AngularJS nu merge nicăieri încă. De fapt, AngularJS vede încă dezvoltarea continuă și sprijinul echipei.
**actualizare**
Angular este în prezent la v6 și este potrivit pentru aplicații de producție mari. Dacă construiți o nouă aplicație astăzi, vă rugăm să vă uitați la Angular 6+.
Consultați noul nostru ghid pentru crearea de componente extrem de reutilizabile cu Angular
dezvoltatorii ar putea favoriza, de asemenea, comunitatea bogată de dezvoltatori și bibliotecile open source din jurul AngularJS, care se opun scufundării în altele noi și limitate. Există mai multe motive pentru care poate doriți să creați o aplicație în AngularJS. Dacă migrarea aplicației ng1 în ng2 + este pe radar, atunci luați în considerare componentizarea aplicației dvs. o condiție prealabilă pentru migrarea dvs.
caracteristici noi de la 1.5.x au fost adăugate retroactiv, în principal suportul componentelor și legarea datelor unidirecționale. Vom căuta cum să maximizăm aceste caracteristici pentru a crea componente extrem de reutilizabile pentru aplicațiile AngularJS care se aliniază mai aproape de noul cadru Angular.
organizarea componentelor
este ușor să te pierzi în componenta aceasta, componenta care hoopla. Una dintre cele mai critice piese de înțeles este ce componentă ar trebui să fie responsabilă pentru ce.
păstrați Componentele la nivel de pagină ca forță motrice din spatele unei vizualizări în timp ce utilizați componente reutilizabile sau “prost” pentru a avea grijă de sarcina comună.
aceasta păstrează logica specifică paginii la o singură componentă în timp ce încapsulează tot codul de rutină și funcționalitatea în bucăți reutilizabile.
una dintre cele mai mari greșeli pe care le-am văzut este transmiterea datelor către componentele copiilor care modifică datele, presupun un caz de utilizare foarte specific sau comunică prin servicii peste tot. Acest lucru le face în cele din urmă greu de înțeles/testat și nu reutilizabile deloc, deoarece devin greu codificate la cazuri de utilizare specifice.
prima ta componentă “Hello World”
cea mai simplă componentă posibilă ar arăta cam așa. Observați cât de asemănătoare sunt directivele.
angular.module('app', )
.component('myComponent', {
template:'<h1>Hello World</h1>'
}
);
este demn de remarcat faptul că directivele sunt încă disponibile dezvoltatorilor. Există câteva circumstanțe rare în care veți dori în continuare să utilizați o directivă șablon peste o componentă. Eventual, dacă ați fost dependent de unele compila sau link-ul de fază…. dar directivele ar trebui folosite ca atribute pentru a adăuga alte funcționalități unei componente … de exemplu, poate ați dorit să adăugați securitate bazată pe permisiune dacă o componentă ar trebui să fie disponibilă sau nu pentru un utilizator.
în caz de îndoială favorizează modelul component. Doriți să construiască aplicația ca un arbore de componente. A se vedea AngularJS docs pentru mai multe informații despre componente vs directive. Directivele ar trebui să fie gândite la componente fără șabloane utilizate pentru a îmbunătăți componentele.
Opțiuni de legare
parametrii componentelor sunt trecuți prin proprietatea bindings. Similar cu vechiul mod de atribuire a variabilelor domeniului de aplicare al Directivei.
angular.module('myApp')
.component('myComponent', {
template:'<h1>$ctrl.name</h1>',
bindings:{
name: '<' //one way data binding
},
controller: function(){
//component controller }})* < - One way data bindingUtilize one-way data binding for your bindings. Two way data bindings were great and one of the neatest feature of AngularJS, but it comes at a performance cost with the bound properties being watched within the component scope. This also means anything you change in component scope would be reflected in the parent in a two-way binding.!Important! - Its important to note that objects are passed by reference instead of a new copy. This means if your bound property is an object or array, changes to these objects would indeed reflect changes in the parent scope and still give you a two way data binding result. This is why its important to not mutate the object/array in the component scope and make those changes in the parent.* = - Two way data bindingNo worries if you need it though. Two way data binding is still around. #yolo* & - Output event. Provides a hook to parent componentsBindings marked with '&' signify a parameter that accepts a callback function from the parent component. This allows the parent to listen or catch any changes/messages. This is how our "dumb" component will talk back to the parent component with the change or event.* @ - String input
comunicare componentă
să presupunem că facem o aplicație messenger. Vizualizarea principală este o componentă la nivel de pagină cu o componentă de listă de contacte reutilizabilă. Dorim să folosim componenta listă de contacte în alte domenii ale aplicației noastre, deci este important să facem acest lucru cât mai reutilizabil posibil.
componenta lista de contacte are un singur scop. Pentru a face lista de contacte disponibile de pe server și de ieșire selecțiile făcute.
componenta messenger ar trebui să accepte selecțiile făcute din componenta listă de contacte și să le adauge la lista de destinatari.
