Vraag "Denken in AngularJS" als ik een jQuery-achtergrond heb? [Gesloten]


Stel dat ik bekend ben met het ontwikkelen van client-side applicaties in jQuery, maar nu wil ik beginnen met gebruiken angularjs. Kun je de paradigmaverschuiving beschrijven die nodig is? Hier zijn een paar vragen die u kunnen helpen bij het inlijsten van een antwoord:

  • Hoe ontwerp en configureer ik webapplicaties aan de klant anders? Wat is het grootste verschil?
  • Wat moet ik stoppen met doen / gebruiken; Wat moet ik in plaats daarvan doen / gebruiken?
  • Zijn er overwegingen / beperkingen aan de serverkant?

Ik ben niet op zoek naar een gedetailleerde vergelijking tussen jQuery en AngularJS.


4525
2018-02-21 04:09


oorsprong


antwoorden:


1. Ontwerp uw pagina niet en wijzig deze vervolgens met DOM manipulaties

In jQuery ontwerpt u een pagina en maakt u deze dynamisch. Dit komt omdat jQuery is ontworpen voor augmentatie en ongelooflijk is gegroeid uit dat eenvoudige uitgangspunt.

Maar in AngularJS moet u van de grond af beginnen met uw architectuur in gedachten. In plaats van te beginnen met te denken "Ik heb dit stuk van de DOM en ik wil het X laten maken", moet je beginnen met wat je wilt bereiken, dan gaan over het ontwerpen van je applicatie en dan eindelijk gaan over het ontwerpen van je visie.

2. Verbeter jQuery niet met AngularJS

Evenzo, begin niet met het idee dat jQuery X, Y en Z doet, dus ik zal daarover alleen nog AngularJS toevoegen voor modellen en controllers. Dit is werkelijk verleidelijk als je net begint, daarom raad ik altijd aan dat nieuwe AngularJS-ontwikkelaars helemaal geen gebruik maken van jQuery, in ieder geval totdat ze eraan wennen de dingen te doen op de "Angular Way".

Ik heb hier veel ontwikkelaars en op de mailinglijst deze uitgebreide oplossingen zien maken met jQuery-plug-ins van 150 of 200 regels code die ze vervolgens in AngularJS lijmen met een verzameling callbacks en $applys die verwarrend en ingewikkeld zijn; maar uiteindelijk werken ze eraan! Het probleem is dat in meest gevallen dat de jQuery-plug-in in AngularJS in een fractie van de code kan worden herschreven, waardoor plotseling alles begrijpelijk en rechtlijnig wordt.

De bottom line is deze: bij het oplossen, eerst "denk in AngularJS"; als je geen oplossing kunt bedenken, vraag het dan aan de gemeenschap; als er na dat alles geen gemakkelijke oplossing is, dan voel je vrij om te reiken naar de jQuery. Maar laat jQuery geen kruk worden of je zult AngularJS nooit onder de knie krijgen.

3. Denk altijd in termen van architectuur

Dat weet ik eerst toepassingen met één pagina zijn toepassingen. Zij zijn niet webpagina's. We moeten dus denken als een server-side ontwikkelaar Daarnaast denken als een ontwikkelaar aan de clientzijde. We moeten nadenken over het verdelen van onze applicatie in individuele, uitbreidbare, testbare componenten.

Dus dan hoe doe je dat? Hoe "denk je in AngularJS"? Hier zijn enkele algemene principes, in contrast met jQuery.

Het uitzicht is het "officiële record"

In jQuery wijzigen we de weergave programmatisch. We kunnen een vervolgkeuzemenu laten definiëren als een ul zoals zo:

<ul class="main-menu">
    <li class="active">
        <a href="#/home">Home</a>
    </li>
    <li>
        <a href="#/menu1">Menu 1</a>
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li>
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li>
        <a href="#/home">Menu 2</a>
    </li>
</ul>

In jQuery zouden we in onze applicatielogica het activeren met iets als:

$('.main-menu').dropdownMenu();

Als we alleen naar de weergave kijken, is het niet meteen duidelijk dat hier functionaliteit beschikbaar is. Voor kleine toepassingen is dat prima. Maar voor niet-triviale toepassingen worden dingen snel verwarrend en moeilijk te onderhouden.

In AngularJS is de weergave echter het officiële record van op weergave gebaseerde functionaliteit. Onze ul verklaring zou er als volgt uitzien:

<ul class="main-menu" dropdown-menu>
    ...
</ul>

Deze twee doen hetzelfde, maar in de AngularJS-versie weet iedereen die naar de sjabloon kijkt, wat er moet gebeuren. Telkens wanneer een nieuw lid van het ontwikkelteam aan boord komt, kan ze dit bekijken en vervolgens weten dat er een richtlijn wordt genoemd dropdownMenu erop werken; ze hoeft niet het juiste antwoord te geven of code te doorzoeken. Het uitzicht vertelde ons wat er moest gebeuren. Veel schoner.

Ontwikkelaars die voor AngularJS nieuw zijn, stellen vaak een vraag als: hoe vind ik alle links van een specifiek soort en voeg ik een richtlijn eraan toe. De ontwikkelaar is altijd verbluft als we antwoorden: jij niet. Maar de reden dat je dat niet doet is dat dit half-jQuery, half-AngularJS en niet-goed is. Het probleem hier is dat de ontwikkelaar "jQuery" probeert te doen in de context van AngularJS. Dat gaat nooit goed werken. Het uitzicht is het officiële record. Buiten een richtlijn (meer hierover hieronder), je nooit, nooit nooit verander de DOM. En richtlijnen worden toegepast in de weergave, zo is intentie duidelijk.

Let op: niet ontwerpen en markeren. Je moet een architect ontwerpen en vervolgens ontwerpen.

Dataverbinding

Dit is verreweg een van de meest geweldige functies van AngularJS en maakt een einde aan de noodzaak om de DOM-manipulaties uit te voeren die ik in de vorige sectie heb genoemd. AngularJS zal uw weergave automatisch bijwerken, zodat u dat niet hoeft te doen! In jQuery reageren we op gebeurtenissen en werken we vervolgens inhoud bij. Zoiets als:

$.ajax({
  url: '/myEndpoint.json',
  success: function ( data, status ) {
    $('ul#log').append('<li>Data Received!</li>');
  }
});

Voor een weergave die er als volgt uitziet:

<ul class="messages" id="log">
</ul>

Afgezien van het mengen van zorgen, hebben we ook dezelfde problemen van intentieverklaringen die ik eerder heb genoemd. Maar wat nog belangrijker is, we moesten handmatig een DOM-knooppunt raadplegen en bijwerken. En als we een logboekinvoer willen verwijderen, moeten we dat ook tegen de DOM coderen. Hoe testen we de logica, afgezien van de DOM? En wat als we de presentatie willen wijzigen?

Dit is een beetje rommelig en een beetje kwetsbaar. Maar in AngularJS kunnen we dit doen:

$http( '/myEndpoint.json' ).then( function ( response ) {
    $scope.log.push( { msg: 'Data Received!' } );
});

En ons beeld kan er als volgt uitzien:

<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

Maar wat dat betreft, zou ons beeld er als volgt kunnen uitzien:

<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

En nu gebruiken we in plaats van een ongeordende lijst Bootstrap-waarschuwingsvakken. En we hoefden nooit de controllercode te veranderen! Maar wat nog belangrijker is, maakt niet uit waar of hoe het logboek wordt bijgewerkt, de weergave zal ook veranderen. Automatisch. Netjes!

Hoewel ik dit hier niet heb laten zien, is de gegevensbinding tweerichtingsverkeer. Die log-berichten kunnen dus ook in de weergave bewerkbaar zijn door dit simpelweg te doen: <input ng-model="entry.msg" />. En er was veel vreugde.

Verschillende modellaag

In jQuery lijkt de DOM op het model. Maar in AngularJS hebben we een aparte modellaag die we kunnen beheren op elke manier die we willen, volledig onafhankelijk van het uitzicht. Dit helpt voor de bovenstaande databinding, onderhoudt scheiding van zorgen, en introduceert een veel grotere testbaarheid. Andere antwoorden noemden dit punt, dus ik zal het daar maar bij laten.

Scheiding van zorgen

En al het bovenstaande sluit aan bij dit overkoepelende thema: houd uw zorgen gescheiden. Uw mening fungeert als de officiële registratie van wat er zou moeten gebeuren (voor het grootste deel); uw model vertegenwoordigt uw gegevens; u hebt een servicelaag om herbruikbare taken uit te voeren; je doet DOM-manipulatie en vergroot je visie met richtlijnen; en je lijmt alles samen met controllers. Dit werd ook genoemd in andere antwoorden, en het enige dat ik zou toevoegen, heeft betrekking op de toetsbaarheid, die ik in een andere sectie hieronder bespreek.

Afhankelijkheid injectie

Om ons te helpen met de scheiding van zorgen is afhankelijkheid injectie (DI). Als u afkomstig bent van een server-side taal (uit Java naar PHP) je bent waarschijnlijk al bekend met dit concept, maar als je een client-side bent die uit jQuery komt, kan dit concept van stom tot overbodig tot hipster lijken. Maar het is niet. :-)

Vanuit een breed perspectief, betekent DI dat je componenten heel vrij kunt declareren en dan van een ander onderdeel gewoon om een ​​exemplaar ervan kunt vragen en deze wordt toegekend. U hoeft niets te weten over het laden van bestellingen of bestandslocaties of iets dergelijks. Het vermogen is misschien niet meteen zichtbaar, maar ik zal slechts één (veelvoorkomend) voorbeeld geven: testen.

Laten we zeggen dat we in onze applicatie een service nodig hebben die server-side opslag implementeert via een RUST UIT API en, afhankelijk van de toepassingstatus, ook lokale opslag. Bij het uitvoeren van tests op onze controllers, willen we niet communiceren met de server - we testen de controleur, ten slotte. We kunnen gewoon een nepservice toevoegen met dezelfde naam als ons oorspronkelijke onderdeel, en de injector zorgt ervoor dat onze controller de nep automatisch ontvangt - onze controller heeft het verschil niet en hoeft het niet te weten.

Over testen gesproken ...

4. Testgestuurde ontwikkeling - altijd

Dit maakt echt deel uit van deel 3 over architectuur, maar het is zo belangrijk dat ik het als een eigen sectie op het hoogste niveau zet.

Van de vele jQuery-plug-ins die u hebt gezien, gebruikt of geschreven, hoeveel van hen hadden een bijhorend testsuite? Niet heel veel omdat jQuery daar niet erg vatbaar voor is. Maar AngularJS is.

In jQuery is de enige manier om te testen vaak om de component onafhankelijk te maken met een voorbeeld / demopagina waartegen onze tests DOM-manipulatie kunnen uitvoeren. Dus dan moeten we een component apart ontwikkelen en dan integreer het in onze applicatie. Hoe onhandig! Veel van de tijd, bij het ontwikkelen met jQuery, kiezen we voor iteratief in plaats van testgestuurde ontwikkeling. En wie kan ons de schuld geven?

Maar omdat we zorgen van elkaar scheiden, kunnen we in AngularJS itentatief een door tests aangedreven ontwikkeling uitvoeren! Laten we bijvoorbeeld zeggen dat we een supereenvoudige richtlijn willen om in ons menu aan te geven wat onze huidige route is. We kunnen verklaren wat we willen in de weergave van onze applicatie:

<a href="/hello" when-active>Hello</a>

Oké, nu kunnen we een test schrijven voor het niet-bestaande when-active richtlijn:

it( 'should add "active" when the route changes', inject(function() {
    var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope );

    $location.path('/not-matching');
    expect( elm.hasClass('active') ).toBeFalsey();

    $location.path( '/hello' );
    expect( elm.hasClass('active') ).toBeTruthy();
}));

En als we onze test uitvoeren, kunnen we bevestigen dat deze mislukt. Alleen nu zouden we onze richtlijn moeten maken:

.directive( 'whenActive', function ( $location ) {
    return {
        scope: true,
        link: function ( scope, element, attrs ) {
            scope.$on( '$routeChangeSuccess', function () {
                if ( $location.path() == element.attr( 'href' ) ) {
                    element.addClass( 'active' );
                }
                else {
                    element.removeClass( 'active' );
                }
            });
        }
    };
});

Onze test is nu geslaagd en ons menu presteert zoals gevraagd. Onze ontwikkeling is beide iteratieve en -Getest. Wicked-cool.

5. Conceptueel zijn richtlijnen niet verpakt jQuery

Je zult vaak horen "doe DOM-manipulatie alleen in een richtlijn". Dit is een noodzaak. Behandel het met gepaste eerbied!

Maar laten we een beetje dieper duiken ...

Sommige richtlijnen decoreren gewoon wat er al in de weergave is (denk ngClass) en daarom soms soms DOM-manipulatie en dan zijn ze in feite klaar. Maar als een richtlijn als een "widget" is en een sjabloon heeft, zou dat moeten ook respecteer scheiding van zorgen. Dat wil zeggen, de sjabloon te moet grotendeels onafhankelijk blijven van de implementatie in de functies link en controller.

AngularJS wordt geleverd met een hele reeks hulpmiddelen om dit zeer eenvoudig te maken; met ngClass we kunnen de klas dynamisch updaten; ngModel maakt tweewegsbinding mogelijk; ngShow en ngHide programmatisch een element tonen of verbergen; en nog veel meer - inclusief degene die we zelf schrijven. Met andere woorden, we kunnen allerlei soorten awesomeness doen zonder DOM-manipulatie. Hoe minder DOM-manipulatie, hoe eenvoudiger richtlijnen zijn om te testen, hoe gemakkelijker ze zijn om te stijlen, hoe gemakkelijker ze in de toekomst zullen veranderen en hoe meer herbruikbaar en distribueerbaar ze zijn.

Ik zie veel nieuwe ontwikkelaars die AngularJS gebruiken met behulp van richtlijnen als de plaats om een ​​heleboel jQuery te gooien. Met andere woorden, ze denken "aangezien ik geen DOM-manipulatie in de controller kan doen, zal ik die code in een richtlijn opnemen". Hoewel dat zeker veel beter is, is het vaak nog steeds fout.

Denk aan de logger die we in sectie 3 hebben geprogrammeerd. Zelfs als we dat in een richtlijn plaatsen, wij nog steeds wil het doen de "Angular Way". Het nog steeds geen DOM-manipulatie nodig! Er zijn veel momenten waarop DOM-manipulatie noodzakelijk is, maar het is een lot zeldzamer dan je denkt! Voordat u DOM-manipulatie uitvoert overal in uw toepassing, vraag uzelf af of dat echt nodig is. Er is misschien een betere manier.

Hier is een kort voorbeeld van het patroon dat ik het vaakst zie. We willen een knop om te schakelen. (Opmerking: dit voorbeeld is een beetje gekunsteld en een skosh-samenvatting om ingewikkelder gevallen weer te geven die op precies dezelfde manier worden opgelost.)

.directive( 'myDirective', function () {
    return {
        template: '<a class="btn">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            var on = false;

            $(element).click( function () {
                on = !on;
                $(element).toggleClass('active', on);
            });
        }
    };
});

Daar zijn een paar dingen mis mee:

  1. Ten eerste was jQuery nooit nodig. Er is niets dat we hier hebben gedaan dat jQuery nodig heeft!
  2. Ten tweede, zelfs als we al jQuery op onze pagina hebben, is er geen reden om het hier te gebruiken; we kunnen gewoon gebruiken angular.element en onze component werkt nog steeds wanneer deze wordt neergezet in een project zonder jQuery.
  3. Ten derde, zelfs uitgaande van jQuery was vereist om deze richtlijn te laten werken, jqLite (angular.element) zullen altijd gebruik jQuery als het is geladen! Dus we hoeven de. Niet te gebruiken $ - we kunnen gewoon gebruiken angular.element.
  4. Ten vierde, nauw verwant aan de derde, is dat jqLite-elementen niet ingepakt hoeven te worden $ - de element dat wordt doorgegeven aan de link functie zou al zijn een jQuery-element!
  5. En ten vijfde, wat we in de vorige paragrafen hebben genoemd, waarom mengen we sjabloommateriaal in onze logica?

Deze richtlijn kan worden herschreven (zelfs voor zeer gecompliceerde gevallen!), Veel eenvoudiger dan dat:

.directive( 'myDirective', function () {
    return {
        scope: true,
        template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            scope.on = false;

            scope.toggle = function () {
                scope.on = !scope.on;
            };
        }
    };
});

Nogmaals, het sjabloommateriaal bevindt zich in de sjabloon, dus u (of uw gebruikers) kunt het gemakkelijk omruilen voor een sjabloon dat aan elke gewenste stijl voldoet, en de logica hoefde nooit aangeraakt te worden. Herbruikbaarheid - boem!

En er zijn nog steeds alle andere voordelen, zoals testen - het is gemakkelijk! Wat de sjabloon ook is, de interne API van de richtlijn wordt nooit aangeraakt, dus refactoring is eenvoudig. U kunt de sjabloon zo vaak wijzigen als u wilt zonder de richtlijn aan te raken. En wat u ook verandert, uw tests slagen nog steeds.

w00t!

Dus als richtlijnen niet alleen een verzameling van jQuery-achtige functies zijn, wat zijn ze dan? Richtlijnen zijn eigenlijk uitbreidingen van HTML. Als HTML niets doet wat je moet doen, schrijf je een richtlijn om het voor je te doen en gebruik je het alsof het een onderdeel van HTML is.

Anders gezegd, als AngularJS iets niet uit de doos doet, bedenk dan hoe het team het zou volbrengen om er precies bij te passen ngClick, ngClass, et al.

Overzicht

Gebruik zelfs geen jQuery. Neem het niet eens op. Het zal je tegenhouden. En wanneer je een probleem tegenkomt waarvan je denkt dat je het al in jQuery weet op te lossen, voordat je naar de $, probeer na te denken over hoe het moet binnen de grenzen van de AngularJS. Als je het niet weet, vraag het dan! 19 keer van de 20, de beste manier om het te doen heeft geen jQuery nodig en om het op te lossen met jQuery resultaten in meer werk voor jou.


7187
2018-02-21 21:26



Imperative → declarative

In jQuery, selectors worden gebruikt om te vinden DOM elementen en vervolgens event-handlers aan hen binden / registreren. Wanneer een gebeurtenis wordt geactiveerd, wordt die (imperatieve) code uitgevoerd om de DOM bij te werken / te wijzigen.

In AngularJS wil je denken keer bekeken in plaats van DOM-elementen. Weergaven zijn (declaratieve) HTML die AngularJS bevatten richtlijnen. Directives zetten de event-handlers achter de schermen voor ons op en geven ons dynamische databinding. Selectors worden zelden gebruikt, dus de behoefte aan ID's (en sommige soorten klassen) is sterk verminderd. Meningen zijn gebonden aan modellen (via scopes). Aanzichten zijn een projectie van het model. Gebeurtenissen veranderen modellen (dat wil zeggen, gegevens, scopeigenschappen) en de weergaven die die modellen projecteren, worden "automatisch" bijgewerkt.

Denk in AngularJS aan modellen in plaats van door jQuery geselecteerde DOM-elementen die uw gegevens bevatten. Denk aan views als projecties van die modellen, in plaats van het registreren van callbacks om te manipuleren wat de gebruiker ziet.

Scheiding van zorgen

jQuery gebruikt onopvallend JavaScript - gedrag (JavaScript) is gescheiden van de structuur (HTML).

AngularJS gebruikt controllers en richtlijnen (die elk hun eigen controller en / of compileer- en koppelingsfuncties kunnen hebben) om gedrag uit de view / structuur (HTML) te verwijderen. Angular heeft ook Diensten en filters om uw applicatie te scheiden / organiseren.

Zie ook https://stackoverflow.com/a/14346528/215945

Applicatie ontwerp

Eén benadering voor het ontwerpen van een AngularJS-applicatie:

  1. Denk aan je modellen. Maak services of uw eigen JavaScript-objecten voor die modellen.
  2. Bedenk hoe u uw modellen wilt presenteren - uw inzichten. Maak HTML-sjablonen voor elke weergave, gebruik de nodige richtlijnen om dynamische databinding te krijgen.
  3. Voeg een controller toe aan elke weergave (met behulp van ng-view en routing of ng-controller). Laat de controller alleen de modelgegevens vinden die de weergave nodig heeft om zijn werk te doen. Maak controllers zo dun mogelijk.

Prototypische erfenis

Je kunt veel met jQuery doen zonder te weten hoe de overerving van JavaScript-prototypes werkt. Bij het ontwikkelen van AngularJS-applicaties vermijd je een aantal veelvoorkomende valkuilen als je een goed begrip hebt van JavaScript-overerving. Aanbevolen lezen: Wat zijn de nuances van scope prototyping / prototypische overerving in AngularJS?


408
2018-02-21 04:09



AngularJS versus jQuery

AngularJS en jQuery hanteren heel verschillende ideologieën. Als je van jQuery komt, zul je sommige verschillen misschien verrassend vinden. Angular kan je boos maken.

Dit is normaal, je moet doorgaan. Hoekig is het waard.

Het grote verschil (TLDR)

jQuery geeft je een toolkit voor het selecteren van willekeurige bits van de DOM en het maken van ad-hoc wijzigingen daarin. Je kunt vrijwel alles wat je wilt stuk voor stuk doen.

AngularJS geeft je in plaats daarvan een compiler.

Wat dit betekent is dat AngularJS je hele DOM van boven naar beneden leest en behandelt als code, letterlijk als instructies voor de compiler. Terwijl het de DOM doorkruist, zoekt het specifiek richtlijnen (compiler-richtlijnen) die de AngularJS-compiler vertellen hoe te handelen en wat te doen. Richtlijnen zijn kleine objecten vol JavaScript die kunnen worden vergeleken met attributen, tags, klassen of zelfs opmerkingen.

Wanneer de Angular-compiler bepaalt dat een stuk van de DOM overeenkomt met een bepaalde instructie, wordt de richtlijn-functie aangeroepen, geeft deze het DOM-element, alle kenmerken, de huidige $ -scope (die een lokaal variabel archief is) en enkele andere nuttige bits door. Deze attributen kunnen uitdrukkingen bevatten die door de richtlijn kunnen worden geïnterpreteerd en die aangeven hoe ze moeten worden weergegeven en wanneer ze zichzelf opnieuw moeten opstellen.

Richtlijnen kunnen dan op hun beurt extra Angular-componenten toevoegen, zoals controllers, services, enz. Wat uit de onderkant van de compiler komt, is een volledig gevormde webapplicatie, bedraad en klaar voor gebruik.

Dit betekent dat Angular Template Driven is. Je sjabloon stuurt JavaScript aan, niet andersom. Dit is een radicale omkering van rollen, en het tegenovergestelde van het onopvallende JavaScript dat we de afgelopen tien jaar of zo hebben geschreven. Dit kan even wennen zijn.

Als dit klinkt alsof het te prescriptief en beperkend is, kan niets verder van de waarheid zijn. Omdat AngularJS uw HTML als code behandelt, krijgt u Grofheid op HTML-niveau in uw webapplicatie. Alles is mogelijk en de meeste dingen zijn verrassend eenvoudig als je een paar conceptuele sprongen maakt.

Laten we naar de kern van de zaak gaan.

Ten eerste vervangt Angular jQuery niet

Angular en jQuery doen verschillende dingen. AngularJS biedt u een set hulpprogramma's om webtoepassingen te maken. jQuery biedt voornamelijk tools voor het aanpassen van de DOM. Als jQuery op uw pagina aanwezig is, zal AngularJS het automatisch gebruiken. Als dat niet zo is, wordt AngularJS geleverd met jQuery Lite, wat een verspannen, maar nog steeds perfect bruikbare versie van jQuery is.

Misko houdt van jQuery en heeft er geen bezwaar tegen dat je het gebruikt. U zult echter merken dat u al uw werk gedaan kunt krijgen met behulp van een combinatie van scope, sjablonen en richtlijnen, en dat u deze workflow waar mogelijk moet verkiezen omdat uw code discreter, configureerbaarder en meer zal zijn. hoekig.

Als je jQuery gebruikt, zou je het niet overal moeten besprengen. De juiste plaats voor DOM-manipulatie in AngularJS is een richtlijn. Hierover later meer.

Onopvallend JavaScript met kiezers versus declaratieve sjablonen

jQuery wordt meestal onopvallend toegepast. Uw JavaScript-code is gekoppeld in de koptekst (of de voettekst) en dit is de enige plaats waar deze wordt genoemd. We gebruiken selectors om stukjes van de pagina te selecteren en plug-ins te schrijven om die delen aan te passen.

JavaScript heeft de controle. De HTML heeft een volledig onafhankelijk bestaan. Uw HTML blijft semantisch, zelfs zonder JavaScript. Onclick-kenmerken zijn erg slechte praktijken.

Een van de eerste dingen die je opvalt aan AngularJS is dat aangepaste kenmerken zijn overal. Uw HTML wordt bezaaid met ng-kenmerken, die in feite onClick-kenmerken zijn op steroïden. Dit zijn richtlijnen (compilerrichtlijnen) en vormen een van de belangrijkste manieren waarop de sjabloon aan het model is gekoppeld.

Wanneer je dit voor het eerst ziet, loop je mogelijk in de verleiding om AngularJS uit te schrijven als intrusieve JavaScript op de oude school (zoals ik aanvankelijk deed). In feite speelt AngularJS niet volgens die regels. In AngularJS is uw HTML5 een sjabloon. Het is samengesteld door AngularJS om uw webpagina te produceren.

Dit is het eerste grote verschil. Voor jQuery is uw webpagina een DOM die moet worden gemanipuleerd. Voor AngularJS is je HTML code die moet worden gecompileerd. AngularJS leest in je hele webpagina en compileert het letterlijk in een nieuwe webpagina met behulp van de ingebouwde compiler.

Uw sjabloon moet declaratief zijn; de betekenis ervan moet duidelijk zijn door het simpelweg te lezen. We gebruiken aangepaste kenmerken met betekenisvolle namen. We verzinnen nieuwe HTML-elementen, opnieuw met betekenisvolle namen. Een ontwerper met minimale HTML-kennis en geen codeervaardigheid kan uw AngularJS-sjabloon lezen en begrijpen wat hij doet. Hij of zij kan wijzigingen aanbrengen. Dit is de hoekige manier.

De sjabloon bevindt zich op de bestuurdersstoel.

Een van de eerste vragen die ik mezelf stelde bij het starten van AngularJS en het doorlopen van de tutorials is "Waar is mijn code?". Ik heb geen JavaScript geschreven en toch heb ik al dit gedrag. Het antwoord is duidelijk. Omdat AngularJS de DOM compileert, behandelt AngularJS uw HTML als code. Voor veel eenvoudige gevallen volstaat het om gewoon een sjabloon te schrijven en AngularJS het in een toepassing voor u te laten compileren.

Uw sjabloon stimuleert uw applicatie. Het wordt behandeld als een DSL. U schrijft AngularJS-componenten en AngularJS zorgt ervoor dat ze worden ingetrokken en ze op het juiste moment beschikbaar worden gemaakt op basis van de structuur van uw sjabloon. Dit is heel anders dan een standaard MVC patroon, waarbij de sjabloon alleen voor uitvoer is.

Het lijkt meer op XSLT dan Ruby on Rails bijvoorbeeld.

Dit is een radicale omkering van controle die even wennen is.

Stop met proberen uw applicatie uit uw JavaScript te halen. Laat de sjabloon de applicatie aansturen en laat AngularJS zorg dragen voor de bedrading van de componenten. Dit is ook de hoekige manier.

Semantische HTML versus semantische modellen

Met jQuery moet je HTML-pagina semantische zinvolle inhoud bevatten. Als het JavaScript is uitgeschakeld (door een gebruiker of een zoekmachine), blijft uw inhoud toegankelijk.

Omdat AngularJS uw HTML-pagina behandelt als een sjabloon. Het is niet de bedoeling dat de sjabloon semantisch is, omdat uw inhoud doorgaans wordt opgeslagen in uw model, dat uiteindelijk van uw API komt. AngularJS compileert uw DOM met het model om een ​​semantische webpagina te produceren.

Uw HTML-bron is niet langer semantisch, maar uw API en gecompileerde DOM zijn semantisch.

In AngularJS, wat levens in het model betekent, is de HTML slechts een sjabloon, alleen voor weergave.

Op dit punt heb je waarschijnlijk allerlei vragen over SEO en toegankelijkheid, en terecht. Er zijn hier open problemen. De meeste schermlezers zullen nu JavaScript analyseren. Zoekmachines kunnen ook indexeren AJAXed inhoud. Desondanks wilt u zeker weten dat u pushstate-URL's gebruikt en dat u een degelijke sitemap hebt. Kijk hier voor een bespreking van het probleem: https://stackoverflow.com/a/23245379/687677

Scheiding van zorgen (SOC) versus MVC

Scheiding van zorgen (SOC) is een patroon dat opgroeide gedurende vele jaren van webontwikkeling om verschillende redenen, waaronder SEO, toegankelijkheid en browser-incompatibiliteit. Het ziet er zo uit:

  1. HTML - semantische betekenis. De HTML moet op zichzelf staan.
  2. CSS - Styling, zonder de CSS is de pagina nog steeds leesbaar.
  3. JavaScript - Gedrag, zonder het script blijft de inhoud over.

Nogmaals, AngularJS speelt niet volgens hun regels. In een beroerte, AngularJS doet afstand van een decennium aan ontvangen wijsheid en implementeert in plaats daarvan een MVC-patroon waarin de sjabloon niet langer semantisch is, zelfs niet een klein beetje.

Het ziet er zo uit:

  1. Model - uw modellen bevatten uw semantische gegevens. Modellen zijn meestal JSON voorwerpen. Modellen bestaan ​​als attributen van een object genaamd $ scope. U kunt ook handige hulpprogramma-functies opslaan op $ scope die uw sjablonen vervolgens kunnen openen.
  2. Weergave - uw weergaven zijn geschreven in HTML. De weergave is meestal niet semantisch omdat uw gegevens in het model leven.
  3. Controller - Uw controller is een JavaScript-functie die de weergave aan het model koppelt. Zijn functie is om $ scope te initialiseren. Afhankelijk van uw toepassing, kunt u al dan niet een controller maken. U kunt veel controllers op een pagina hebben.

MVC en SOC zijn niet op tegenovergestelde uiteinden van dezelfde schaal, ze zijn op volledig verschillende assen. SOC heeft geen zin in een AngularJS-context. Je moet het vergeten en verder gaan.

Als je, net als ik, de browseroorlogen hebt meegemaakt, vind je dit idee misschien aanstootgevend. Kom er overheen, het is het waard, dat beloof ik.

Plug-ins versus richtlijnen

Plug-ins breiden jQuery uit. AngularJS-richtlijnen breiden de mogelijkheden van uw browser uit.

In jQuery definiëren we plug-ins door functies aan het jQuery.prototype toe te voegen. Vervolgens koppelen we deze aan de DOM door elementen te selecteren en de plug-in op het resultaat te roepen. Het idee is om de mogelijkheden van jQuery uit te breiden.

Als u bijvoorbeeld een carrousel op uw pagina wilt, kunt u een ongeordende lijst met figuren definiëren, misschien ingepakt in een nav-element. Je zou dan wat jQuery kunnen schrijven om de lijst op de pagina te selecteren en het opnieuw te doen als een galerij met time-outs om de glijdende animatie te doen.

In AngularJS definiëren we richtlijnen. Een instructie is een functie die een JSON-object retourneert. Dit object vertelt AngularJS naar welke DOM-elementen moet worden gezocht en welke wijzigingen ze moeten aanbrengen. Richtlijnen worden gekoppeld aan de sjabloon met behulp van attributen of elementen die u zelf uitvindt. Het idee is om de mogelijkheden van HTML uit te breiden met nieuwe attributen en elementen.

De AngularJS manier is om de mogelijkheden van native-look HTML uit te breiden. Je zou HTML moeten schrijven die op HTML lijkt, uitgebreid met aangepaste attributen en elementen.

Als je een carrousel wilt, gebruik dan gewoon een <carousel /> element, definieer vervolgens een richtlijn om een ​​sjabloon in te voeren en die sukkel te laten werken.

Veel kleine richtlijnen versus grote plug-ins met configuratieschakelaars

De neiging van jQuery is om geweldige grote plug-ins zoals lightbox te schrijven die we vervolgens configureren door verschillende waarden en opties door te geven.

Dit is een fout in AngularJS.

Neem het voorbeeld van een vervolgkeuzelijst. Bij het schrijven van een drop-down-plugin kom je misschien in de verleiding om te coderen in click-handlers, misschien een functie om een ​​chevron toe te voegen die omhoog of omlaag is, misschien de klasse van het uitgevouwen element wijzigen, het menu verbergen, alle nuttige dingen.

Totdat je een kleine verandering wilt aanbrengen.

Stel dat u een menu hebt dat u met de zweeftekst wilt uitvouwen. Welnu, we hebben een probleem. Onze plug-in is in onze klik-handler voor ons verbonden, we zullen een configuratie-optie moeten toevoegen om het in dit specifieke geval anders te laten werken.

In AngularJS schrijven we kleinere richtlijnen. Onze dropdown-richtlijn zou belachelijk klein zijn. Het kan de gevouwen status behouden en bieden methoden voor vouwen (), uitvouwen () of schakelen (). Met deze methoden wordt $ scope.menu.visible bijgewerkt. Dit is een Booleaanse naam die de staat bevat.

Nu in onze sjabloon we kunnen dit bespreken:

<a ng-click="toggle()">Menu</a>
<ul ng-show="menu.visible">
  ...
</ul>

Moet u bijwerken over mouseover?

<a ng-mouseenter="unfold()" ng-mouseleave="fold()">Menu</a>
<ul ng-show="menu.visible">
  ...
</ul>

Het sjabloon stuurt de applicatie, zodat we granulariteit op HTML-niveau krijgen. Als we van geval tot geval uitzonderingen willen maken, maakt de sjabloon dit gemakkelijk.

Sluiting vs. $ scope

JQuery-plug-ins worden gemaakt in een afsluiting. Privacy wordt gehandhaafd binnen die sluiting. Het is aan jou om je scopeketen binnen die sluiting te behouden. U hebt alleen echt toegang tot de reeks DOM-knooppunten die door jQuery zijn doorgegeven aan de plug-in, plus eventuele lokale variabelen die in de afsluiting zijn gedefinieerd en alle globals die u hebt gedefinieerd. Dit betekent dat plug-ins behoorlijk onafhankelijk zijn. Dit is een goede zaak, maar kan beperkend worden bij het maken van een hele applicatie. Het proberen van het doorgeven van gegevens tussen secties van een dynamische pagina wordt een hele klus.

AngularJS heeft $ scope-objecten. Dit zijn speciale objecten gemaakt en onderhouden door AngularJS waarin u uw model opslaat. Bepaalde richtlijnen zullen een nieuwe $ scope genereren, die standaard inherent is aan de wrapping $ scope met JavaScript-prototypische overerving. Het $ scope-object is toegankelijk in de controller en de weergave.

Dit is het slimme deel. Omdat de structuur van $ scope inheritance grofweg de structuur van de DOM volgt, hebben elementen toegang tot hun eigen bereik en kunnen scopes naadloos worden opgenomen, helemaal tot aan de globale $ scope (wat niet hetzelfde is als de globale scope).

Dit maakt het veel gemakkelijker om gegevens door te geven en gegevens op een geschikt niveau op te slaan. Als een vervolgkeuzelijst wordt geopend, hoeft alleen de dropdown $ scope hiervan op de hoogte te zijn. Als de gebruiker zijn voorkeuren bijwerkt, wilt u mogelijk het globale $ -bereik bijwerken en worden alle geneste scopes die naar de gebruikersvoorkeuren luisteren automatisch gewaarschuwd.

Dit klinkt misschien ingewikkeld, sterker nog, als je er eenmaal in zit, is het net alsof je vliegt. U hoeft het $ scope-object niet te maken, AngularJS maakt een instantisatie en configureert het voor u, correct en passend op basis van uw sjabloonhiërarchie. AngularJS maakt het vervolgens beschikbaar voor uw component met behulp van de magie van afhankelijkheidsinjectie (hierover later meer).

Handmatige DOM-wijzigingen versus gegevensbinding

In jQuery maak je al je DOM-wijzigingen handmatig. Je bouwt nieuwe DOM-elementen programmatisch. Als u een JSON-array hebt en deze naar de DOM wilt plaatsen, moet u een functie schrijven om de HTML te genereren en in te voegen.

In AngularJS kunt u dit ook doen, maar u wordt aangemoedigd om gebruik te maken van databinding. Wijzig uw model en omdat de DOM hieraan gebonden is via een sjabloon, wordt uw DOM automatisch bijgewerkt, zonder tussenkomst.

Omdat databinding vanuit de sjabloon wordt uitgevoerd met behulp van een attribuut of de accolade van de accolades, is het super eenvoudig om te doen. Er is weinig cognitieve overhead aan verbonden, dus je zult merken dat je het de hele tijd doet.

<input ng-model="user.name" />

Bindt het invoerelement aan $scope.user.name. Als u de invoer bijwerkt, wordt de waarde in uw huidige bereik bijgewerkt en omgekeerd.

Hetzelfde:

<p>
  {{user.name}}
</p>

zal de gebruikersnaam in een paragraaf uitvoeren. Het is een live-binding, dus als het $scope.user.name waarde wordt bijgewerkt, de sjabloon wordt ook bijgewerkt.

Ajax de hele tijd

In jQuery is het maken van een Ajax-oproep vrij eenvoudig, maar het is nog steeds iets waar je misschien twee keer over denkt. Er is de extra complexiteit om over na te denken, en een redelijk stuk script om te onderhouden.

In AngularJS is Ajax uw standaard go-to-oplossing en het gebeurt de hele tijd, bijna zonder dat u het merkt. U kunt sjablonen opnemen met ng-include. U kunt een sjabloon toepassen met de eenvoudigste aangepaste richtlijn. Je kunt een Ajax-oproep verpakken in een service en jezelf maken GitHub service, of een Flickr service, die u met verbazingwekkend gemak kunt openen.

Service-objecten versus helpfuncties

Als we in jQuery een kleine niet-dom gerelateerde taak willen uitvoeren, zoals het ophalen van een feed uit een API, kunnen we een kleine functie schrijven om dat in onze afsluiting te doen. Dat is een geldige oplossing, maar wat als we vaak toegang willen tot die feed? Wat als we die code in een andere applicatie willen hergebruiken?

AngularJS geeft ons service-objecten.

Services zijn eenvoudige objecten die functies en gegevens bevatten. Het zijn altijd eenlingen, wat betekent dat er nooit meer dan één kan zijn. Stel dat we toegang willen tot de Stack Overflow API, we kunnen een a schrijven StackOverflowService die methoden definieert om dit te doen.

Laten we zeggen dat we een winkelwagentje hebben. We kunnen een ShoppingCartService definiëren die onze winkelwagen onderhoudt en bevat methoden voor het toevoegen en verwijderen van items. Omdat de service een singleton is en door alle andere componenten wordt gedeeld, kan elk object dat moet worden naar de winkelwagen worden geschreven en er gegevens uit ophalen. Het is altijd hetzelfde wagentje.

Servicevoorwerpen zijn op zichzelf staande AngularJS-componenten die we kunnen gebruiken en opnieuw kunnen gebruiken zoals we dat nodig achten. Het zijn eenvoudige JSON-objecten met functies en gegevens. Het zijn altijd eenlingen, dus als u gegevens op een dienst op één plaats opslaat, kunt u die gegevens ergens anders ophalen door dezelfde service aan te vragen.

Afhankelijkheid injectie (DI) vs. Instatiation - ook bekend als de-spaghettificatie

AngularJS beheert uw afhankelijkheden voor u. Als u een object wilt, kunt u er eenvoudig naar verwijzen en AngularJS krijgt het voor u.

Totdat je dit begint te gebruiken, is het moeilijk uit te leggen wat een enorme tijdzegen dit is. Er zit niets in AngularJS DI in jQuery.

DI betekent dat in plaats van je applicatie te schrijven en deze samen te bedraden, je in plaats daarvan een bibliotheek met componenten definieert, elk geïdentificeerd door een string.

Stel dat ik een component heb die 'FlickrService' heet en die methoden definieert voor het ophalen van JSON-feeds van Flickr. Als ik nu een controller wil schrijven die toegang heeft tot Flickr, dan moet ik gewoon de naam 'FlickrService' bij naam noemen als ik de controller declareer. AngularJS zorgt ervoor dat het component wordt geïnstantieerd en beschikbaar wordt gemaakt voor mijn controller.

Hier definieer ik bijvoorbeeld een service:

myApp.service('FlickrService', function() {
  return {
    getFeed: function() { // do something here }
  }
});

Wanneer ik nu die service wil gebruiken, verwijs ik het gewoon naar deze naam:

myApp.controller('myController', ['FlickrService', function(FlickrService) {
  FlickrService.getFeed()
}]);

AngularJS zal herkennen dat een FlickrService-object nodig is om de controller te instantiëren en zal er een voor ons beschikbaar stellen.

Dit maakt het aansluiten van dingen heel gemakkelijk en elimineert vrijwel elke neiging tot spagettificatie. We hebben een platte lijst met componenten en AngularJS geeft ze één voor één aan ons door wanneer en wanneer we ze nodig hebben.

Modulaire servicearchitectuur

jQuery zegt heel weinig over hoe je je code moet ordenen. AngularJS heeft meningen.

AngularJS biedt u modules waarin u uw code kunt plaatsen. Als u bijvoorbeeld een script schrijft dat met Flickr praat, wilt u misschien een Flickr-module maken om al uw Flickr-gerelateerde functies in te pakken. Modules kunnen andere modules (DI) bevatten. Uw hoofdtoepassing is meestal een module en dit zou alle andere modules moeten omvatten waarvan uw toepassing afhankelijk is.

Je krijgt eenvoudig hergebruik van code, als je een andere applicatie op basis van Flickr wilt schrijven, kun je gewoon de Flickr-module en voila toevoegen, je hebt toegang tot al je Flickr-gerelateerde functies in je nieuwe applicatie.

Modules bevatten AngularJS-componenten. Wanneer we een module opnemen, komen alle componenten in die module voor ons beschikbaar als een eenvoudige lijst die wordt geïdentificeerd door hun unieke tekenreeksen. We kunnen dan die componenten in elkaar injecteren met AngularJS's afhankelijkheidsinjectiemechanisme.

Op te sommen

AngularJS en jQuery zijn geen vijanden. Het is mogelijk om jQuery binnen AngularJS heel goed te gebruiken. Als u AngularJS goed gebruikt (sjablonen, data-binding, $ scope, richtlijnen, etc.) zult u merken dat u een lot minder jQuery dan je anders zou kunnen vereisen.

Het belangrijkste te realiseren ding is dat uw sjabloon uw toepassing aandrijft. Stop met proberen grote plug-ins te schrijven die alles doen. Schrijf in plaats daarvan kleine richtlijnen die één ding doen en schrijf vervolgens een eenvoudige sjabloon om ze samen te bedraden.

Denk minder na over onopvallend JavaScript en denk in plaats daarvan in termen van HTML-extensies.

Mijn kleine boekje

Ik was zo enthousiast over AngularJS, ik heb er een kort boek over geschreven dat je van harte welkom vindt om online te lezen http://nicholasjohnson.com/angular-book/. Ik hoop dat het nuttig is.


184
2018-05-12 10:22



Kun je de paradigmaverschuiving beschrijven die nodig is?

Imperative versus Declarative

Met jQuery je vertelt de DOM wat er moet gebeuren, stap voor stap. Met angularjs je beschrijft welke resultaten je wilt, maar niet hoe je het moet doen. Meer hierover hier. Bekijk ook het antwoord van Mark Rajcok.

Hoe ontwerp en configureer ik webapp-apps aan de client anders?

AngularJS is een volledig raamwerk aan de clientzijde dat gebruik maakt van de MVC patroon (bekijk hun grafische weergave). Het richt zich enorm op het scheiden van zorgen.

Wat is het grootste verschil? Wat moet ik stoppen met doen / gebruiken; wat moet ik in plaats daarvan doen / gebruiken?

jQueryis een bibliotheek

angularjs is een mooi client-side framework, zeer testbaar, dat tonnen cool spul combineert zoals MVC, afhankelijkheid injectie, data-binding en nog veel meer.

Het richt zich op scheiding van zorgen en testen (testen van een eenheid en end-to-end testen), die testgestuurde ontwikkeling mogelijk maakt.

De beste manier om te beginnen is door te gaan hun geweldige tutorial. Je kunt de stappen in een paar uur doorlopen; Als u echter de concepten achter de schermen onder de knie wilt krijgen, bevatten ze een groot aantal verwijzingen voor verder lezen.

Zijn er overwegingen / beperkingen aan de serverkant?

Je kunt het gebruiken op bestaande applicaties waar je al pure jQuery gebruikt. Als u echter volledig wilt profiteren van de AngularJS-functies, kunt u overwegen de server te coderen met een REST nadering.

Als je dit doet, kun je hun gebruiken bronfabriek, wat een abstractie van je server-side RESTful creëert API en maakt oproepen aan de server (ophalen, opslaan, verwijderen, enz.) ongelooflijk gemakkelijk.


152
2018-02-21 04:29



Om de "paradigmaverschuiving" te beschrijven, kan een kort antwoord volstaan.

AngularJS verandert de manier waarop jij vind elementen

In jQuery, gebruik je meestal selectors om elementen te vinden en ze vervolgens te verbinden:
$('#id .class').click(doStuff);

In angularjs, je gebruikt richtlijnen om de elementen direct te markeren, om ze te verbinden:
<a ng-click="doStuff()">

AngularJS heeft geen behoefte (of wil) dat je elementen vindt met selectors - het belangrijkste verschil tussen AngularJS's jqLite tegen volslagen jQuery is dat jqLite biedt geen ondersteuning voor selectors.

Dus wanneer mensen zeggen "neem jQuery helemaal niet op", komt dit vooral omdat ze niet willen dat je selectors gebruikt; ze willen dat je leert om richtlijnen te gebruiken in plaats daarvan. Direct, niet selecteren!


84
2018-02-21 07:57



jQuery

jQuery maakt belachelijk lange JavaScript-commando's zoals getElementByHerpDerp korter en cross-browser.

angularjs

Met AngularJS kunt u uw eigen HTML-tags / attributen maken die dingen doen die goed werken met dynamische webtoepassingen (aangezien HTML is ontworpen voor statische pagina's).

Bewerk:

Zeggen "Ik heb een jQuery-achtergrond, hoe denk ik dat in AngularJS?" is als zeggen: "Ik heb een HTML-achtergrond, hoe denk ik dat in JavaScript?" Het feit dat u de vraag stelt, toont u waarschijnlijk niet de fundamentele doelen van deze twee bronnen. Daarom koos ik ervoor om de vraag te beantwoorden door simpelweg het fundamentele verschil te benadrukken in plaats van door de lijst te gaan met de tekst: "AngularJS maakt gebruik van richtlijnen terwijl jQuery CSS-selectors gebruikt om een ​​jQuery-object te maken dat dit en dat enz doet ...." . Deze vraag vereist geen langdurig antwoord.

jQuery is een manier om het programmeren van JavaScript in de browser eenvoudiger te maken. Kortere opdrachten voor meerdere browsers, enz.

AngularJS breidt HTML uit, u hoeft dus niet te zetten <div> overal om een ​​applicatie te maken. Het zorgt ervoor dat HTML echt werkt voor applicaties in plaats van waarvoor het is ontworpen, wat statische, educatieve webpagina's zijn. Het volbrengt dit op een omweg met behulp van JavaScript, maar het is fundamenteel een uitbreiding van HTML, niet van JavaScript.


69
2018-02-04 05:07



jQuery: je denkt veel na over 'QUERYing the DOM'voor DOM-elementen en iets doen.

AngularJS: HET model is de waarheid en je denkt altijd vanuit die ANGLE.

Als u bijvoorbeeld gegevens ontvangt van de server die u in een bepaald formaat in de DOM wilt weergeven, moet u in jQuery '1. VIND 'waar in de DOM je deze gegevens wilt plaatsen, de' 2. UPDATE / APPEND 'het daar door een nieuw knooppunt te creëren of gewoon zijn innerHTML. Wanneer u vervolgens deze weergave wilt bijwerken, gaat u naar '3. VIND 'de locatie en' 4. BIJWERKEN'. Deze cyclus van vinden en updaten allemaal gedaan in dezelfde context van het ophalen en formatteren van gegevens van de server is verdwenen in AngularJS.

Met AngularJS heeft u uw model (JavaScript-objecten waaraan u al gewend bent) en de waarde van het model vertelt u over het model (uiteraard) en over de weergave, en een bewerking van het model wordt automatisch naar de weergave doorgevoerd, dus u ik moet erover nadenken. Je zult merken dat je in AngularJS geen dingen meer vindt in de DOM.

Op een andere manier, in jQuery, moet je denken aan CSS-selectors, dat wil zeggen, waar is het div of td die een klasse of attribuut, enz. heeft, zodat ik hun HTML of kleur of waarde kan krijgen, maar in AngularJS zul je merken dat je zo denkt: met welk model heb ik te maken, ik zal de waarde van het model op waar afstemmen. Je bent jezelf niet aan het hinderen of het beeld dat deze waarde weerspiegelt een vakje is of zich in een td element (details waar je vaak aan moest denken in jQuery).

En met DOM-manipulatie in AngularJS, voegt u zelf richtlijnen en filters toe, die u kunt zien als geldige HTML-extensies.

Nog een ding dat je in AngularJS zult ervaren: in jQuery noem je de jQuery-functies veel, in AngularJS zal AngularJS je functies noemen, dus AngularJS zal je 'vertellen hoe je dingen moet doen', maar de voordelen zijn het waard, dus het leren van AngularJS betekent meestal leren wat AngularJS wil of de manier waarop AngularJS vereist dat u uw functies presenteert en het dienovereenkomstig zal noemen. Dit is een van de dingen die AngularJS een kader maakt in plaats van een bibliotheek.


61
2017-11-02 16:53



Dat zijn een paar hele mooie, maar lange antwoorden.

Om mijn ervaringen samen te vatten:

  1. Controllers en providers (services, fabrieken, etc.) dienen voor het modificeren van het datamodel, NIET voor HTML.
  2. HTML en richtlijnen definiëren de lay-out en binding aan het model.
  3. Als u gegevens tussen controllers wilt delen, moet u een service of een fabriek maken. Dit zijn eenlingen die in de toepassing worden gedeeld.
  4. Als u een HTML-widget nodig heeft, maakt u een richtlijn.
  5. Als je wat gegevens hebt en nu HTML probeert bij te werken ... STOP! werk het model bij en zorg ervoor dat uw HTML aan het model is gebonden.

46
2018-05-16 21:50



jQuery is een DOM-manipulatiebibliotheek.

AngularJS is een MV * -raamwerk.

AngularJS is zelfs een van de weinige JavaScript MV * -kaders (veel JavaScript MVC-tools vallen nog steeds onder de categoriebibliotheek).

Omdat het een framework is, host het uw code en neemt het de eigendom van beslissingen over wat te bellen en wanneer!

AngularJS zelf bevat een jQuery-Lite-editie erin. Dus voor sommige eenvoudige DOM-selectie / -manipulatie hoef je de jQuery-bibliotheek echt niet op te nemen (het bespaart vele bytes om op het netwerk uit te voeren.)

AngularJS heeft het concept van "Richtlijnen" voor DOM-manipulatie en het ontwerpen van herbruikbare UI-componenten, dus je zou het moeten gebruiken wanneer je de behoefte voelt om dingen te doen die met DOM-manipulatie te maken hebben (richtlijnen zijn alleen de plaatsen waar je jQuery-code moet schrijven tijdens het gebruik van AngularJS).

AngularJS omvat enige leercurve (meer dan jQuery :-).

-> Voor elke ontwikkelaar die van jQuery-achtergrond komt, zou mijn eerste advies zijn om "JavaScript te leren als eersteklas taal voordat je springt op een rijk framework zoals AngularJS!" Ik heb het bovenstaande feit op de harde manier geleerd.

Succes.


45
2017-10-10 08:58