Share
Er zijn veel JavaScript-bibliotheken beschikbaar en de meeste zijn erg goed in het bieden van de traditionele DOM-gerichte interacties die uw typische websites nodig hebben. Maar wanneer het tijd is om een beheersbare codebasis te bouwen voor een app met één pagina, dan komt daar een hele reeks nieuwe frameworks om dingen glad te strijken.
Het oude gezegde is waar: "Gebruik de beste tool voor de taak."
Het is niet zo dat traditionele bibliotheken zoals jQuery je niet kunnen helpen om desktopachtige ervaringen op te bouwen, het is gewoon niet de use-case en mist dingen als data-binding, routing van gebeurtenissen en staatsbeheer. Natuurlijk kun je waarschijnlijk een aantal plug-ins samenbrengen om een deel van die functionaliteit te bereiken, maar beginnen met een raamwerk dat speciaal is opgebouwd om deze specifieke problemen aan te pakken, vind ik logischer. Het oude gezegde is waar: "Gebruik de beste tool voor de taak."
Ik heb onlangs een interview gedaan met het Ember.js-team; het werd gemotiveerd door mijn verlangen om te leren kennen wat ik 'de nieuwe hotness' ben gaan noemen: Ember.js.
Ember past de rekening voor wat ik hierboven heb beschreven, en doet dat op een manier die doet denken aan een heleboel manieren waarop jQuery ontwikkelaars in staat stelt om snel aan de slag te gaan. Het team heeft opzettelijk stappen ondernomen om veel van de complexiteiten die inherent zijn aan het ontwerpen en bouwen van op Model / View / Controller gebaseerde applicaties te abstraheren met behulp van jarenlange expertise en kennis die is opgedaan bij het bouwen van grootschalige apps.
Wat ik graag zou willen doen, is om je op de hoogte te houden met Ember.js, via een uit meerdere delen bestaande artikelserie die je geleidelijk aan laat kennismaken met de concepten van het raamwerk. We beginnen met de gebruikelijke intro (die toevallig deze post is) en gaan dan geleidelijk aan door met het bouwen van een volledige applicatie. Het grote voordeel is dat dit me ook zal helpen de concepten te versterken die ik al heb geleerd, en misschien onderweg wat nieuwe technieken op te pikken! Ik zal mijn best doen om het team van Ember.js dit materiaal te laten beoordelen op nauwkeurigheid en misschien zelfs een paar klompen mee te delen.
Voordat we verder gaan, heads-up: Ember.js doet veel magie voor je. Soms kijk je naar de code en zeg je "Hoe gaat het met je?" Ik ben er geweest en ik zal mijn best doen om dingen te destilleren, maar ik ga niet in de ingewanden van de kadercode van Sintel duiken. In plaats daarvan zal ik bespreken hoe u de hulpprogramma's en API kunt gebruiken om uw app te bouwen.
Dus laten we beginnen.
Ember.js is geen raamwerk voor het bouwen van traditionele websites.
Het eerste ding om in gedachten te houden is dat Ember.js geen raamwerk is voor het bouwen van traditionele websites. Bibliotheken zoals jQuery en MooTools zijn daar prima geschikt voor. Als u Ember.js overweegt, gaat u ervan uit dat u op zoek bent naar desktopachtige ervaringen, vooral schaalbare. In feite is de slogan voor het raamwerk "een kader voor het ontwikkelen van ambitieuze webtoepassingen", wat aangeeft dat het duidelijk niet de JavaScript-bibliotheek van je vader is.
Ik noemde eerder al dat Ember het MVC-patroon gebruikt voor het bevorderen van correct codebeheer en -organisatie. Als je nog nooit MVC-gebaseerde ontwikkeling hebt gedaan, moet je dit zeker lezen. Nettuts + heeft hier een geweldig artikel over het onderwerp. Voor degenen onder u die bekend zijn met de concepten, moet u zich thuis voelen. Het enige dat ik consequent heb gehoord is dat het maken van de overstap van Backbone naar Ember.js eigenlijk eenvoudig is, omdat Ember veel van het zware werk voor je doet, terwijl de code-organisatiepatronen die deze ontwikkelaars gewend zijn, nog steeds behouden blijven.
Ember vertrouwt ook op client-side templates ... a LOT. Het maakt gebruik van de stuurbibliotheek Middels sjablonen die uitdrukkingen biedt waarmee u dynamische op HTML gebaseerde sjablonen kunt maken. Een ontwikkelaar van Ember kan gegevens aan deze insluitbare expressies binden en de weergave van zijn app dynamisch direct wijzigen. Ik kan bijvoorbeeld een sjabloon maken die een reeks mensen kan ontvangen en deze in een ongeordende lijst kan weergeven:
Let op de "#eache" -uitdrukking die werkt als een lusrichtlijn, die een opsomming geeft van elk element van de "people" -array en de uitdrukking "name" vervangt door een werkelijke waarde. Het is belangrijk op te merken dat de dubbele haakjes tokens zijn die door het stuur worden gebruikt om uitdrukkingen te identificeren. Dit is een klein voorbeeld en we zullen later in meer detail duiken.
Stuur is een ongelooflijk krachtige client-side sjablonengine en ik zou het aanraden om niet alleen de Ember-handleidingen, maar ook de stuurwebsite zelf te lezen om een volledig overzicht te krijgen van de beschikbare opties. Je zult het behoorlijk gebruiken.
Ember.js vertrouwt op extra bibliotheken, dus u moet een kopie van jQuery en Handlebars pakken. Maar wacht, heb ik niet gezegd dat jQuery en Ember in verschillende ruimtes spelen? Nou ja, dat deed ik, maar hier is het ding: het Ember-team draait helemaal niet om het wiel opnieuw uitvinden. Ze kozen voor jQuery om te doen waar het het beste in is: werken met de DOM. En dat is maar goed ook, want jQuery is daar echt goed in. Het is ook waarom ze met Handlebars gingen, wat een uitstekende sjablonerende bibliotheek is die geschreven werd door Yehuda Katz, een lid van het kernteam van Ember..
De gemakkelijkste manier om de bestanden te krijgen die u nodig hebt, is door naar de Github repo van Ember.js te gaan en de starterkit naar beneden te trekken. Het is een standaardplaatje om mee te beginnen. Op het moment van dit schrijven bevat het:
Er is ook een standaard html-sjabloon dat is gecodeerd om alle bijbehorende bibliotheken (jQuery, Ember, etc.) te bevatten, samen met een voorbeeld van een stuursjabloon en "app.js", met code voor het starten van een eenvoudige Ember-app.
Merk op dat app.js geen deel uitmaakt van het framework. Het is een eenvoudig ole JavaScript-bestand; je kunt het alles noemen wat je wilt. En terwijl we het voor de doeleinden van deze tutorialserie gebruiken, zult u waarschijnlijk uw JavaScript opsplitsen in meerdere bestanden, net zoals u zou doen voor elke andere site of app. Bovendien verwacht Ember geen specifieke directorystructuur voor uw kaderbestanden.
Als u naar de code van de Starter Kit kijkt, kan deze op uw standaardwebsitecode lijken. In sommige opzichten heb je gelijk! Zodra we dingen gaan organiseren, zie je hoe het bouwen van een Ember-app anders is.
Voordat u begint met het hacken van code, is het belangrijk om te begrijpen hoe Ember.js werkt en dat u de bewegende delen waaruit een Ember-app bestaat, laat aangroeien. Laten we eens kijken naar die delen en hoe ze zich tot elkaar verhouden.
Sjablonen vormen een belangrijk onderdeel van het definiëren van uw gebruikersinterface. Zoals ik eerder al zei, is Handlebars de client-side bibliotheek die wordt gebruikt in Ember en de uitdrukkingen die door de bibliotheek worden gebruikt, worden op grote schaal gebruikt bij het maken van de gebruikersinterface voor uw toepassing. Hier is een eenvoudig voorbeeld:
Merk op dat de uitdrukkingen worden gemengd in uw HTML-markup en dat zij via Ember de inhoud die op de pagina wordt weergegeven, dynamisch wijzigen. In dit geval worden de tijdelijke aanduidingen firstName en lastName vervangen door gegevens die zijn opgehaald uit de app.
Stuur biedt veel kracht, via een flexibele API. Het is belangrijk voor u om te begrijpen wat het biedt.
De router van een toepassing helpt de status van de toepassing te beheren.
De Router van een toepassing helpt bij het beheren van de staat van de applicatie en de resources die nodig zijn als een gebruiker door de app navigeert. Dit kan taken omvatten zoals het opvragen van gegevens uit een model, het aansluiten van controllers op weergaven of het weergeven van sjablonen.
U doet dit door een route te maken voor specifieke locaties binnen uw applicatie. Routes specificeren delen van de applicatie en de bijbehorende URL's. De URL is de sleutel-ID die door Ember wordt gebruikt om te begrijpen welke applicatiestatus aan de gebruiker moet worden gepresenteerd.
Accentsconagua
App.Router.map (function () this.route ('about'); // Brengt ons naar "/ about"); Het gedrag van een route (bijvoorbeeld: gegevens opvragen van een model) wordt beheerd via exemplaren van het Ember-routevoorwerp en wordt geactiveerd wanneer een gebruiker naar een specifieke URL navigeert. Een voorbeeld is het opvragen van gegevens van een model, zoals dit:
App.EmployeesRoute = Ember.Route.extend (model: function () return App.Employee.find (););
In dit geval, wanneer een gebruiker naar het gedeelte "/ medewerkers" van de toepassing navigeert, vraagt de route aan het model om een lijst met alle werknemers..
Een objectrepresentatie van de gegevens.
Modellen zijn een objectrepresentatie van de gegevens die uw toepassing zal gebruiken. Het kan een eenvoudige array zijn of gegevens die dynamisch worden opgehaald uit een RESTful JSON API, via een Ajax-aanvraag. De Ember Data-bibliotheek biedt de API voor het laden, in kaart brengen en bijwerken van gegevens naar modellen binnen uw toepassing.
Controllers worden meestal gebruikt om modeldata en attributen op te slaan en weer te geven. Ze werken als een proxy, waardoor u toegang krijgt tot de attributen van het model en waardoor sjablonen toegang hebben tot deze attributen om het scherm dynamisch te renderen. Daarom wordt een sjabloon altijd verbonden met een controller.
Het belangrijkste om te onthouden is dat, terwijl een model gegevens ophaalt, een controller is wat u zult gebruiken om die gegevens programmatisch bloot te stellen aan verschillende delen van uw toepassing. Hoewel het lijkt alsof modellen en controllers nauw gekoppeld zijn, hebben modellen zelf geen kennis van de controllers die ze later zullen gebruiken.
U kunt ook andere appeleigenschappen opslaan die moeten blijven bestaan, maar niet op een server hoeven te worden opgeslagen.
Weergaven in Ember.js zijn bedoeld om evenementen rond gebruikersinteractie te beheren en deze te vertalen naar evenementen die betekenis hebben binnen uw applicatie. Dus als een gebruiker op een knop klikt om een medewerker te verwijderen, is de weergave verantwoordelijk voor het interpreteren van die native browser-klikgebeurtenis en deze op de juiste manier verwerken binnen de context van de huidige staat van uw applicatie.
Een van de manieren waarop Ember.js de benodigde hoeveelheid code minimaliseert en dingen voor u achter de schermen aanpakt, is door conventies te benoemen. De manier waarop u uw routes (en bronnen) definieert en benoemt, heeft invloed op de naamgeving van uw controllers, modellen, weergaven en sjablonen. Als ik bijvoorbeeld een route maak, 'medewerkers' genoemd:
App.Router.map (function () this.resource ('employees');); Ik zou dan mijn componenten een naam geven, zoals dit:
Het gebruik van deze naamconventie heeft een tweeledig doel. Ten eerste geeft het je een semantische relatie tussen dezelfde componenten. Ten tweede kan Sintel automatisch de noodzakelijke objecten maken die mogelijk niet bestaan (bijvoorbeeld: een routevoorwerp of een controller) en ze verbinden voor gebruik in uw toepassing. Dit is de "magie" die ik eerder noemde. In feite is dit specifiek wat Ember doet op het algemene toepassingsniveau, wanneer u het Application-object instelt:
var App = Ember.Application.create ();
Die ene regel maakt de standaardreferenties naar de router, controller, weergave en sjabloon van de applicatie.
Terugkomend op de "medewerkers" -route die ik hierboven heb gecreëerd, zal wat er gebeurt, is dat, wanneer een gebruiker navigeert naar "/ employees" in uw toepassing, Ember naar de volgende objecten zal zoeken:
Als het deze niet vindt, maakt het een exemplaar van elk bestand, maar geeft het simpelweg niets terug, omdat u geen model hebt opgegeven om gegevens van af te leiden of een sjabloon om de gegevens mee weer te geven. Daarom is de naamgevingsconventie zo belangrijk. Hiermee kan Ember weten hoe de taken van een specifieke route moeten worden afgehandeld, zonder dat u dingen handmatig hoeft af te handelen.
Merk op dat ik in het eerste voorbeeld de enkelvoudige naam "Werknemer" gebruikte om het model te definiëren. Dat is expres. De aard van de naam "Medewerkers" dicteert dat ik misschien met 0 tot veel werknemers werk, dus het is belangrijk om een model te bouwen dat de flexibiliteit kan bieden om één werknemer of alle werknemers terug te sturen. De enkelvoudige naamgevingsconventie van dit model is geen vereiste voor Sintel, omdat modellen zelf geen kennis hebben van de controllers die ze later zullen gebruiken. U hebt dus de flexibiliteit om ze te benoemen, maar voor consistentie zal het volgen van deze conventie het beheren van uw code aanzienlijk eenvoudiger maken.
Ook heb ik ervoor gekozen om de middelen () methode om mijn route te definiëren, omdat ik in dit scenario waarschijnlijk geneste routes zou hebben om detailpagina's te beheren voor specifieke werknemersinformatie. We zullen later in de serie over nesten praten.
De belangrijkste afleiding is dat door een consistent naamgevingsschema te gebruiken, Ember eenvoudig de hooks kan beheren die deze componenten aan elkaar binden zonder dat je de relaties expliciet hoeft te definiëren via een hoop code.
Volledige details van de naamgevingsconventies van Ember zijn te vinden op de site van het project en is een moet lezen.
In het volgende deel van de serie duiken we in de code om de basis voor onze toepassing te creëren.
We hebben de kernbegrippen van Sintel besproken en de belangrijkste aspecten op hoog niveau van het raamwerk besproken. In het volgende deel van de serie duiken we in de code om de basis voor onze toepassing te creëren. In de tussentijd wil ik opnieuw aanbevelen dat u begint te kijken naar de documentatie voor Handlebars om een idee te krijgen van de expressiesyntaxis. En als je echt een beetje aan het kwijlen bent om in Ember te komen, houd dan Tuts + Premium in de gaten, die binnenkort een volledige cursus zal bieden die je helpt bij het bouwen van een op Ember gebaseerde applicatie!
Zoals ik aan het begin van dit artikel opmerkte, leidde Ember.js Core Team Yehuda Katz en Tom Dale dit voor nauwkeurigheid en gaf het de duimen omhoog. Ember-team goedgekeurd! Ik zie je een beetje!
