Roman Lipsky

Softwareverdenen udvikler sig nu med en enorm hastighed. For bare et par år siden var stationære computere og bærbare computere de vigtigste enheder til webudvikling. I dag er tingene slet ikke sådan.

Universelle webapplikationer erstatter mere gammeldags desktopapplikationer inden for mange forretningsområder. Hvorfor? Fordi de bevarer funktionalitet på alle enheder, er baseret i skyen og generelt er meget mere bekvemme at bruge.

Nogle mener, at browserbaserede webapplikationer gradvist bliver erstattet af mobilapplikationer med deres enorme kundebaser. Men sandheden er, at webapplikationer er mere levende end nogensinde, og efterspørgslen efter dem vokser kun.

Hvis du overvejer at udvikle en webapplikation til din virksomhed, ved du sikkert allerede, at der er to hovedtilgange til udvikling: Du kan oprette både enkeltsidesapplikationer (SPA'er) og flersidesapplikationer (MPA'er).

Ligesom alt andet i vores liv, har begge designmuligheder deres fordele og ulemper. Før du begynder at implementere dine ideer, skal du træffe flere vigtige beslutninger.

For at beslutte, hvilken web-app-model der er bedst for din virksomhed, skal du altid fokusere på det indhold, som dine kunder værdsætter højest, for uden indhold vil du simpelthen ikke være i stand til at tiltrække kunder til at bruge dine webprodukter.

Derfor er de vigtigste spørgsmål i første fase, hvilken slags indhold du vil promovere til din målgruppe, og hvad der er vigtigst for, at de kan samarbejde med dig.

Som vi nævnte ovenfor, har både SPA og MPA deres fordele og ulemper. Lad os forstå forskellen mellem de to typer applikationer og prøve at finde den rigtige webudviklingsløsning til din virksomhed.

For at gøre dette vil vi bede direktøren for BLAKIT-webafdelingen, Vitaly Ozersky, om at give sine ekspertkommentarer om emnet. Vi håber, at vi sammen kan gøre dette valg lettere for dig.

Enkeltsideapplikationer

Enkeltsideapplikationer kører i browseren og kræver ikke genindlæsning af sider eller indlæst yderligere sider under brug. Sådanne applikationer bruges dagligt af millioner af brugere uden selv at bemærke det. De mest populære eksempler: GitHub, Gmail, Google Maps og endda Facebook.

Vitaly Ozersky: Enkeltside-applikationer er som regel så interaktive som muligt, så meget, at brugeren får følelsen af, at han arbejder med en desktop-applikation: applikationens reaktion på brugerhandlinger er i de fleste tilfælde øjeblikkelig. På denne måde sammenligner SPA'er sig positivt med sites med flere sider, hvor brugeren ved hver handling skal vente på, at en ny side indlæses.

Enkeltsideapplikationer er designet specifikt til at give brugerne en fantastisk UX, der ligner et "naturligt" browsermiljø uden sidegenindlæsninger og derfor ingen forsinkelser i fuldførelsen af ​​handlinger.

En typisk enkeltsideapplikation ligner en webside, der indlæser og opdaterer indhold uden at genindlæse ved hjælp af JavaScript. SPA anmoder om sidelayout og indhold og opretter derefter den endelige sidevisning direkte i browseren. Denne effekt kan opnås takket være avancerede JavaScript-rammer såsom AngularJS, Ember.js, Meteor.js, Knockout.js.

I: Ud over de vigtigste populære rammer er BLAKIT-udviklere også i stand til at udvikle enkeltside-applikationer ved hjælp af ReactJS.

Den største fordel ved React er dens lave indgangstærskel. React er ret nemt at bruge; Næsten enhver udvikler, der er fortrolig med HTML, kan oprette React-applikationer.

En anden fordel er muligheden for at skrive applikationer til web- og mobilplatforme ved hjælp af en enkelt teknologistack.

Vi bruger React sammen med Redux-biblioteket, som giver os mulighed for at lægge den rigtige arkitektur og skabe komplekse webapplikationer, der er nemme at skalere.

Set fra almindelige brugeres synspunkt er den største UX-fordel ved enkeltsideapplikationer, at alt indhold præsenteres på en tilgængelig og funktionel måde, uden at det er nødvendigt at hoppe fra side til side.

Fordele ved enkeltsideapplikationer:

• SPA'er er kendetegnet ved fremragende ydeevne, da de fleste af de ressourcer, de bruger (HTML + CSS + Scripts), kun indlæses én gang under en session med applikationen. Efter at have udført handlinger på siden, er det kun data, der ændres.
• Udvikling af webapplikationer er normalt hurtigere og mere effektivt. Det er ikke nødvendigt at skrive separat kode for at gengive siden på serversiden. Det er også meget nemmere at begynde at udvikle sådanne applikationer, fordi du kan begynde at skrive kode fra file://URI uden at bruge nogen server.
• SPA'er er optimeret til Chrome-fejlretning, hvilket giver udviklere mulighed for at spore netværksaktivitet og undersøge sideelementer og data forbundet med dem.
• Hvis du allerede har en SPA, vil du være i stand til at oprette en mobilapplikation med samme backend.
• SPA'er er mere effektive til at cache data på lokale medier. Applikationen sender én anmodning, indsamler alle de nødvendige data, og fra det øjeblik kan den fungere selv offline.

Ulemper ved enkeltsideapplikationer:

• SEO-optimering til enkeltside-applikationer er af indlysende årsager ikke særlig let. Applikationsindhold indlæses ved hjælp af AJAX (Asynchronous JavaScript og XML), en metode til at udveksle data og opdatere applikationen uden at genindlæse siden, mens SEO-optimering er baseret på vedvarende indhold på hver enkelt side. Det er dog ikke umuligt at promovere dit websted i søgemaskiner. Mange ændringer af SEO kan foretages på serversiden, og virksomheder som Google fortsætter med at komme med nye løsninger, der kan gøre livet lettere for både spa-ejere og deres brugere.
• De tager ret lang tid at indlæse, da tunge rammer på klientsiden først skal indlæses i browseren.
• SPA'er kræver, at JavaScript er aktivt i brugernes browsere. Hvis nogen af ​​dine kunder manuelt deaktiverer JavaScript, vil de ikke være i stand til at drage fuld fordel af din applikation. Selvom du cacher og renderer dine sider på serversiden (hvilket nu er muligt), risikerer du stadig ikke at levere alle funktionerne i din enkeltsideapplikation i den korrekte form til ikke-JS-brugere.
• Sammenlignet med traditionelle applikationer er SPA'er lidt mindre sikre. Takket være cross-site scripting (XSS) er angribere i stand til at injicere yderligere scripts på klientsiden.
• Nogle JavaScript-hukommelseslækager kan forårsage ydeevneforringelse selv på kraftige systemer

Det er også nyttigt at vide, at alle de problemer, der er forbundet med brugen af ​​enkeltsideapplikationer, gradvist bliver løst, da mange virksomheder, herunder teknologivirksomheder, tilskynder til denne form for forhold til kunder på internettet.

I: SPA'er er velegnede til enhver virksomhed, der har brug for at automatisere sine processer. Men for f.eks. virksomheders websteder og online kataloger er det bedre at bruge mere traditionelle websteder.

Flersidede applikationer

Multipage apps fungerer på en mere traditionel måde, så at sige. Enhver væsentlig dataændring eller upload af information tilbage til serveren medfører, at en ny side gengives i browseren. Multi-side apps er naturligvis tungere end enkelt-side apps og har typisk til formål at vise mere indhold.

Kompleksiteten og omkostningerne ved at udvikle MPA'er er højere og kræver også et flerlags UI-design. Heldigvis er dette ikke længere et så stort problem, da AJAX kun giver dig mulighed for at opdatere visse dele af applikationen i stedet for at overføre en masse data mellem servere og browsere.

Fordele ved flersidede applikationer:

• Dette er den mest velegnede mulighed for brugere, der ønsker en mere visuelt klar grænseflade og velkendt navigation gennem applikationen. MPA'er oprettes typisk med menuer på flere niveauer og andre navigationsværktøjer.
• Væsentligt forenklet SEO. Du kan optimere hver enkelt side i applikationen til de søgeord, du har brug for.

Ulemper ved flersidede applikationer:

• Frontend- og backend-udvikling er i dette tilfælde meget tæt kombineret.
• MPA-udvikling er ret kompleks, da det kræver brug af frameworks på både klient- og serversiden. Udviklingstid og omkostninger er derfor ikke så behageligt for mange virksomheder.

SPA eller MPA?

Før du beslutter dig for at udvikle en webapplikation, skal du først huske formålet med dens oprettelse. Hvis du i erhvervslivet skal beskæftige dig med en lang række forskellige varer og tjenester, vil en flersidet hjemmeside være den optimale løsning for dig.

Hvis du leder efter maksimal funktionalitet i et fortættet webhotel, er en enkeltsidet webapplikation det rigtige valg. Og hvis SPA-funktionaliteten passer til dine behov, men du ikke kan forestille dig, hvordan alt dit indhold skal placeres på én side, bør du overveje et hybridwebsted.

Vi har endnu ikke nævnt denne form for webudvikling i artiklen. En hybrid app sigter mod at tage det bedste fra begge verdener og samtidig minimere ulemperne.

Teknisk set er en hybrid-app stadig en SPA, men den bruger URL-ankre som syntetiske sider og forbedrer derved browserens native navigation og indstillingsfunktionalitet.

Fortæl os, hvis du vil vide mere om hybrid-apps, vi vil skrive en separat artikel om dem.

Det menes nu, at næsten alle virksomheder i den nærmeste fremtid vil skifte til en enkeltsidet eller hybrid applikationsmodel, da denne arkitektur har flere fordele for både udviklere og brugere.

Ifølge vores data skifter mange typer virksomheder allerede til denne model i deres online promoveringsstrategi. Men nogle typer projekter kan simpelthen ikke implementeres som SPA: De har simpelthen for meget indhold. Derfor har MPA-modellen i hvert fald i en overskuelig fremtid stadig en plads.

I: Jeg er fuldstændig enig i udsagnet om den voksende popularitet af enkeltsideapplikationer. I dag er der stor efterspørgsel efter SPA-applikationer, da virksomheder gradvist overfører deres software fra desktop-applikationer til applikationer, der er tilgængelige fra enhver browser, og ikke kun på en Windows-pc.

Enkeltsideapplikation eller SPA - enkeltside applikation - et websted eller en webapplikation baseret på et enkelt HTML-dokument. Typisk er JavaScript-frameworks (“frameworks” til udvikling) som AngularJS, BackboneJS, Ember.js osv. forbundet med en HTML-side. Disse rammer giver dig mulighed for at vise forskelligt indhold på siden, afhængigt af brugeren handlinger og/eller status for sidens URL . Tilstandsændringer kan forekomme, når der klikkes på links, href hvilken består af et URL-fragment, der starter med tegnet "#".. Nogle gange med et par tegn "#!", i tilfælde af søgemaskinepromovering af dette websted (i Yandex).

Indholdet af et sådant websted indlæses fra serveren ved hjælp af AJAX - asynkron JavaScript og XML. For at implementere arbejde via AJAX skal du også implementere en del af applikationen på serversiden. Scriptsprog er almindeligt anvendt. For nem betjening og systemskalering skal du vælge HVILE(arkitektur af interaktion mellem applikationsdele).

Single Page Application og JavaScript Frameworks

Forskellige rammer bruges til at bygge enkeltsidede applikationer:

• backbone.js (russisk) - et letvægtsbibliotek skrevet af CoffeeScript og brugt til at udvikle SPA-sider med understøttelse af REST-arkitektur
• ember.js (russisk) - også en gratis JavaScript-ramme baseret på Model-View-Controller-moduler (udviklingsmønster - MVC)
• angular.js (russisk) - framework, MVC. En af forfatterne arbejder videre med rammeværket, mens han arbejder hos Google.

En side hjemmeside html

Kan bygges ved hjælp af vælgere efter identifikator og målvælger :mål, CSS-egenskaber til at kontrollere indholdets synlighed (visning, synlighed og margen). Én-sides hjemmesideskabeloner indeholder alt det nødvendige indhold, for at den besøgende kan arbejde. I dette enkleste tilfælde er der ingen grund til at forbinde JS-frameworks.

Pseudo-class:target giver dig mulighed for at vælge HTML-elementer på siden, hvis id-attribut matcher hash-værdien fra adresselinjen. For eksempel, hvis URI'en er til stede i adresselinjen: http://site/test-po-html#result, så vil et element med identifikatoren #result blive fundet på HTML-siden, og CSS-stile vil blive anvendt på det .

Rammen på en sådan side kan se sådan ud (bemærk! For nemheds skyld er den samme højde brugt til alle sider. I praksis vil indholdsmængden være forskellig)

Container( font: 1em sans-serif; width:600px; min-height:500px; margin:auto; border:1px solid #000; position: relative; ) h1,h2,h3,h4,h5,h6 (margin: 0 ;).page( width:600px; højde:430px; position: absolut; top:60px; display: none; background-color: #fff; ) div:first-of-type( display:block; z-index: 1 ; ) div:target( display:blok; z-indeks: 2; )

Se et eksempel på arbejde. Med sider, der bruger JS frameworks, arbejdes der på en anden måde.

, , Kommentarer: 0

Web Tools 2012.2-opdateringen til ASP.NET MVC 4-projekter tilføjede en ny skabelon - Single Page Application (SPA). Denne skabelon er designet til hurtigt at bygge interaktive webapplikationer på klientsiden.

"Single Page Application" (SPA) er den grundlæggende betegnelse for webapplikationer, der indlæser én side og derefter opdaterer den dynamisk uden at indlæse andre sider. Hovedsiden indlæses, og derefter kommunikerer applikationen med serveren ved hjælp af AJAX-anmodninger.

AJAX er ikke nyt, men i dag findes der Javascript-biblioteker, der gør det nemmere at udvikle og vedligeholde store, komplekse enkeltsidede applikationer. Og HTML5 og CSS3 hjælper med at skabe en smuk brugergrænseflade.

Lad os se på et eksempel på at bygge en webapplikation ved hjælp af en en-sides skabelon. Lad os bygge en applikation, der administrerer en huskeliste.

Opret en ny enkeltsideapplikation

For at oprette en applikation skal du bruge:

• Visual Studio 2012 eller Visual Studio Express 2012 til web
• ASP.NET Web Tools 2012.2-opdatering, du kan installere den herfra.

Åbn hovedmenuen i Visual Studio-applikationen Fil->Ny -> Projekt. Fra de foreslåede projektskabeloner vil vi vælge ASP.NET MVC 4 webapplikation.

Lad os starte applikationen. En login-formular åbnes.

Lad os registrere.

Efter at have logget ind på appen, oprettes en standardto-do-liste med to elementer, og en "Tilføj opgaveliste"-knap vises for at tilføje en ny liste.

Enkeltside applikationsarkitektur

Diagrammet viser applikationens hovedblokke.

På serversiden genererer ASP.NET MVC HTML og administrerer også formulargodkendelse. ASP.NET Web API håndterer alle anmodninger om to-do-lister og to-do-listepunkter. Disse er modtagelse, oprettelse, opdatering og sletning. Klienten udveksler data med Web API i JSON-format.

Entity Framework er et ORM-lag (object relational mapping), der forbinder applikationens objektorienterede arkitektur til databasen. Den anvendte database er lokal (LocalDb), men du kan også forbinde din egen i web.config-filen. Til lokal udvikling bruges typisk en lokal database, og ved hjælp af en EF-kode-først-migrering overføres den til SQL-serveren.

21. maj , 2017

Single-side sites eller Single Page Applications (SPA) er seje. Deres største fordel er, at SPA er hurtigere og mere lydhør over for brugerhandlinger. Dette opnås ved at overføre arbejdslogikken til klientsiden og aktiv interaktion med serveren via ajax.

Der er en opfattelse af, at SPA'er er kraftfulde applikationer i Angular eller React, der flytter tonsvis af data i et kontrolpanel eller i en kompleks tjeneste. Og generelt er dette sandt. Men jeg er overbevist om, at det giver mening at skrive enkeltsidede applikationer ikke kun til sådanne tjenester, men også til almindelige virksomhedsvisitkortsider.

Hvorfor er dette nødvendigt, og hvordan gør man det med en lille indsats? Mere om dette nedenfor. Gå.

Så hvorfor denne forkælelse?

Det vigtigste er arbejdshastigheden.

Når vi udvikler et visitkortwebsted med én side, vil vi naturligvis støde på nogle problemer:

• 1. Hvordan skal man henvende sig, hvor skal man begynde?
• 2. Hvordan håndterer man browserhistorik, med History API?
• 3. Hvilket framework eller bibliotek skal jeg studere: Angular, React? Og vi kender ikke en eneste...
• 4. Hvordan tvinger man søgemaskiner til at indeksere et enkeltsides websted?

Svar på disse spørgsmål:

• 1. Lad os se på det i samme artikel ved at bruge eksemplet med en simpel hjemmeside
• 2. Jeg vil også fortælle dig nedenfor, dette er et dusin linjer kode
• 3. Ingen, vi nøjes med native javascript og jQuery som assistent
• 4. Den næste artikel i denne serie vil handle om søgemaskiner.

Hvorfor uden vinkel-reager?
Selvfølgelig er disse meget nødvendige emner, jeg anbefaler at studere dem. Men for vores eksempel vil de ikke være nødvendige, vi behøver kun at have minimal viden om javascript.

One-pagers er emnet for mere end én artikel. Dette bliver et helt projekt, en serie artikler på mindst tre stykker. Og det vil dække en række forskellige emner. Men lad mig præcisere. Vi vil bygge et simpelt adminpanel med interaktion med serveren via REST API (i hvert fald i begyndelsen). I de første lektioner vil vores ensides hjemmeside være et almindeligt visitkort på et dusin sider. Men siden vil fungere uden at genindlæse sider og vil glæde vores brugere med hastigheden og reaktionsevnen af ​​grænsefladen.

Ideen med webstedet, hvordan det fungerer

Lad os tage den mest almindelige virksomhedshjemmeside: Hjemmeside, afsnit "Om projektet", kontakter og blog. Blogsektionen vil have flere links til interne sider. På hver side vil vi tilføje noget indhold og indsætte nogle krydsreferencer.

Hver side på et websted har typisk gentaget indhold. For os vil dette være en overskrift og en menu. Og der er hovedindholdet på siden, der ændrer sig. Vi vil gøre dette: Vi indlæser siden kun én gang, og ved at klikke på linkene indlæser vi dynamisk det nødvendige indhold ved hjælp af Ajax. Samtidig vil vi ændre sidetitlen i browserfanen, url'en i adresselinjen og huske historikken i browseren, så navigation gennem browserens Tilbage/Frem-knapper fungerer.

Indhold for hver enkelt side vil blive gemt i en separat html-fil.

Du kan med det samme se, hvad vi ender med -

Site struktur og forberedende arbejde

Filmappestrukturen er som følger. I roden af ​​projektet er der en fil index.php og .htaccess. Jeg fortæller dig hvorfor PHP og ikke html senere. Css-mappen indeholder stilarter i main.css-filen. Js-mappen indeholder jquery.js-biblioteket og hovedprogramfilen main.js. Sider-mappen indeholder html-filer med indholdet af siden - en fil for hver side.

Forberedelse af indhold

Jeg vil lave en demoside med mit webdevkin-projekt som eksempel. Sættet af sider vil se sådan ud:

• — hoved - Hjem
• — om - Om projektet
• — blog - Blog
• — butik - Netbutikker
• — frontend - Frontend
• — mysql - MySql-database
• — widgets - Integrerbare widgets
• — simple - Project Simple
• — kontakter - Kontakter

Følgelig vil sider-mappen indeholde 9 html-filer. Du kan finde alle markeringer for indholdet i . Som et eksempel vil jeg kun give indholdet af én fil - simple.html

Simple-projektet voksede ud af et blogwebsted. Ideen med projektet er at lave enkle og let indlejrede widgets, der hjælper med at interagere med besøgende på dit websted. Lige nu er der allerede en undersøgelseswidget, der er nem at oprette og integrere på ethvert websted.

Som du kan se, er der ingen hoved, krop, html, script her - kun markup relateret til en specifik side.

index.php og .htaccess

Hvorfor ikke index.html?
Faktum er, at der på vores side vil være én enkelt fysisk side - indeks. Men vi er også interesserede i sådanne adresser som site.ru/about, site.ru/contacts osv. Men der er ingen om- og kontaktsider i roden af ​​vores websted. Sider-mappen med et sæt html-filer er ikke en fuldgyldig side, men blot stykker html-kode, der er indbygget i den overordnede ramme.

Derfor, for at vi ikke får 500, 403, og gud ved hvilke andre fejl, når vi går ind på site.ru/about, skal vi omdirigere alle indkommende anmodninger til webstedet til index.php, som vil løse disse anmodninger. Men indtil videre er vores index.php almindelig html-markering uden en enkelt linje php-kode (men dette er kun for nu). Og i .htaccess vil vi skrive følgende. Du skal sjældent vende tilbage til det.

RewriteEngine On Options +SymLinksIfOwnerMatch RewriteCond %(REQUEST_FILENAME) !-d RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-l RewriteRule ^$1.php?q$index=(.php)?q$index

Til sagen
Jeg skrev engang en artikel om en Simple RESTful-tjeneste i native PHP. Der vil du finde lidt mere information om denne metode til at omdirigere anmodninger.

Vores html-kode vil være meget enkel. Css/main.css stilarter er inkluderet i head. Der er 2 js-filer i sidefoden: js/jquery.js og js/main.js. Og i kroppen vil der være følgende:

Først viser vi menuen. Dernæst kommer sidetitlen. Og nedenfor er en tom div med id=content (vær ikke opmærksom på style="" - parseren vil en dag pisse mig af, og jeg erstatter den). #content vil dynamisk indlæse sideindhold fra pages/*.html-filer. Intet interessant endnu.

Vær bare opmærksom på attributterne data-menu og data-link="ajax" for links. De introduceres for at skelne navigationslinks fra almindelige eksterne links, som også vil være på vores hjemmeside. data-link="ajax" betyder, at når du klikker på dette link, opsnapper vi browserens standardadfærd og tager arbejdet med linket i vores egne hænder. Og data-menu betyder, hvilket hovedmenupunkt der bliver fremhævet, når du klikker på dette link. Her er data-menuen duplikeret med href-attributten, men andre muligheder er mulige. For eksempel, når vi går til frontend-sektionen af ​​bloggen, vil vi angive data-menu="blog".

2 eksempler for klarhed:

simple.ru Hjemmeside simple.ru

main.css stilarter

Lad os hurtigt scrolle igennem og copy-paste den mest kedelige del - css/main.css filen.

Body (position: relativ; font-family: "Helvetica Neue Light", "Helvetica Neue-Light", "Helvetica Neue", Calibri, Helvetica, Arial; skriftstørrelse: 1em; font-weight: 400; farve: #333 ; ) a, a:visited ( farve: steelblue; ) a:hover ( farve: navy; ) .wrapper ( bredde: 80%; margin: 0 10%; ) .spa-title ( font-size: 1.2em; text - align: center; ) menu ( margin-top: 2em; polstring: 0; text-align: center; ) menu a ( display: inline-blok; margin-right: 10px; polstring: 5px 15px; tekst-dekoration: ingen ; ) menu a:hover, menu a.active (baggrundsfarve: stålblå; farve: hvid; ) .page-title (tekst-align: center;) ul li (liste-stil-type: cirkel;)

Nu kommer den mest interessante del - javascript-koden, der vil gøre vores sæt af individuelle filer til en en-sides hjemmeside.

javascript Generel kode og konfigurationer

Lad os sætte js-koderammerne.

Var app = (function() ( var config = (); var ui = (); // Hændelsesbindingsfunktion _bindHandlers() ( // ... ) // Applikationsinitieringsfunktion init() ( // ... _bindHandlers (); ) // Return outside return ( init: init ) ))(); // Start applikationen $(document).ready(app.init);

Vi har et separat app-modul, som kører sin init-funktion, når siden indlæses. I den vedhæfter vi hændelseshandlere og eksekverer noget mere kode. Vi ser også 2 objekter: config og ui. Alle dom-elementer, som vi skal bruge i vores arbejde, bliver cachelagret i ui'en.

Var ui = ( $body: $("body"), $menu: $("#menu"), $pageTitle: $("#page-title"), $content: $("#content") );

Vi har brug for $menu for at fremhæve individuelle menupunkter, $pageTitle vil blive ændret dynamisk, når der flyttes mellem sider, og $content vil blive indlæst med indholdet af siderne/*.html-filerne

Men config ser mere interessant ud.

Var config = ( siteTitle: "Webdevkin SPA", hovedside: "main", sider: ( hoved: ( titel: "Main", menu: "main"), om: ( titel: "Om projektet", menu: " om " ), blog: ( titel: "Webdevkin-a Blog", menu: "blog"), simpel: ( titel: "Simpelt projekt", menu: "simpelt"), kontakter: ( titel: "Kontakter", menu : "kontakter" ), shop: ( titel: "Online butikker", menu: "blog"), frontend: ( titel: "Artikler om frontend", menu: "blog"), mysql: ( titel: "Mysql Database ", menu: "blog" ), widgets: (titel: "Indlejrbare javascipt-widgets", menu: "blog") ) );

siteTitle: "Webdevkin SPA" - sitetitel, brugt flere steder.
mainPage: "main" - angiv startsiden på webstedet, den, der åbnes, når du indtaster site.ru. Nu er dette hovedsiden, men det kan nemt falde dig ind at sætte startsiden f.eks. "Om projektet" - ca.

Det vigtigste i hele konfigurationen er pages-objektet. Hvert objektfelt beskriver en side på webstedet. Nu mangler vi kun 2 elementer: sidetitlen og menuen, som denne side tilhører. Objektnøglerne, det vil sige siderne, matcher filnavnene i pages/*.html og href-attributterne i interne links.

Og til sidst skriver vi koden, som vi startede det hele for. Du kan blive overrasket, men koden, der direkte udfører arbejdet med at vedligeholde webstedet, er meget mindre end forberedelsen til at skrive den.

Indlæser indhold ved hjælp af ajax. Historie API

Lad os gå i rækkefølge. Lad os arbejde på init-funktionen, som indeholder bindingen af ​​de nødvendige hændelser _bindHandlers

// Hændelsesbindingsfunktion _bindHandlers() ( ui.$body.on("klik", "a", _navigate); window.onpopstate = _popState; )

I den første linje fanger vi klik på interne links a og sender dem til funktionen _navigate. Nu er vi endelig overbevist om, at separate attributter data-link="ajax" er nødvendige :-)

Næste window.onpopstate = _popState;
Fra dokumentationen.
Popstate-hændelsen sendes til vinduesobjektet, når den aktive historikindgang skifter mellem to historikindgange for det samme dokument.
Kort sagt, dette er betjeningen af ​​Tilbage/Frem-knapperne i browseren. Som vi kan se, skal browserens oprindelige adfærd også opsnappes. Derfor vil vi give kontrol til _popState-funktionen.

For en bedre forståelse vil jeg give koden til begge funktioner på én gang

// Klik på linkfunktionen _navigate(e) ( e.stopPropagation(); e.preventDefault(); var page = $(e.target).attr("href"); _loadPage(page); history.pushState( ( page: page), "", page); )

Når der sker et eksplicit klik på linket _navigate, stopper vi klikhændelsen i at boble og annullerer browserens standardadfærd (ved at følge linket). Vi identificerer derefter den side, vi vil indlæse (forstået af href-attributten) og kalder den nye _loadPage-funktion. Hun vil gøre alt det vigtigste arbejde med at indlæse indhold, ændre titlen og så videre. Og til sidst, ved at bruge history.pushState, tilføjer vi en ny post i browserhistorikken. Ja, vi selv opretter eksplicit browserhistorikken. Så når vi finder det nødvendigt. Og vi gemmer dataene om den indlæste side i et objekt (side: side). Disse data vil være nyttige for os i den næste _popState-funktion.

I _popState er ideen den samme: vi leder efter den ønskede side og starter den samme _loadPage.

Var side = (e.stat && e.state.side) || config.mainPage;

e.state && e.state.page - trækker en side ud til os fra historieobjektet, som vi forsigtigt optog i _navigate. Hvis e.state-objektet ikke er tilgængeligt (for eksempel da vi første gang besøgte site.ru-webstedet og endnu ikke har haft tid til at vandre rundt på det), så tager vi den side, der er angivet som den vigtigste i vores config - config. Forside.
Retfærdigvis er history.pushState-funktionen og det faktum, at et e.state-objekt med data skrevet til pushState er tilgængeligt i window.onpopstate, alt, hvad vi behøver at vide om History API. For mere nysgerrige kammerater er jeg ikke i tvivl om, at google vil hjælpe dig med at finde andre gode måder at arbejde med browserhistorik på.

Vi vil ikke engagere os i dyb research, men vil skrive koden til hovedfunktionen _loadPage

// Indlæs indhold efter sidefunktion _loadPage(page) ( var url = "pages/" + page + ".html", pageTitle = config.pages.title, menu = config.pages.menu; $.get(url, funktion) (html) ( document.title = pageTitle + " | " + config.siteTitle; ui.$menu.find("a").removeClass("active"); ui.$menu.find("a").addClass ("aktiv"); ui.$pageTitle.html(pageTitle) ui.$content.html(html));

Han ser ganske almindelig ud. Først danner vi url'en, det vil sige stien, hvor vi vil downloade html'en til siden. Derefter trækker vi sidetitlen og menupunktet ud, der skal vælges fra konfigurationen. Dernæst får vi html-indholdet på siden gennem den banale jQuery.get og udfører en række simple handlinger.

a) Opdater sidetitlen
b) Vælg det ønskede menupunkt på 2 linjer
c) Skift titlen på selve siden, i html-koden
d) Indlæs det faktiske html-indhold på siden hentet fra url'en

Næsten alle! Der er et lille øjeblik tilbage. Hvis vi nu for eksempel går ind på site.ru/blog-siden og opdaterer den, så bliver det ikke bloggen, der indlæses, men en tom side. For under initialisering kalder vi ikke _loadPage. For at rette op på dette skal vi tilføje et par linjer til init-funktionen, som i sidste ende vil se sådan ud

// Initialiser applikationsfunktionen init() ( var page = document.location.pathname.substr(1) || config.mainPage; _loadPage(page); _bindHandlers(); )

Det er alt sikkert nu!

Lad os opsummere og huske linkene

Så vi skrev en enkel, men fuldt funktionel én-sides hjemmeside, og lærte også lidt om, hvordan History API fungerer. Helt ærligt, så føler jeg mig som instruktøren af ​​en dårlig film, hvor 80% af tiden fører til en form for grandiose udfald, og i sidste ende viser alt sig at være meget nemmere end forventet.

På den ene side er næsten al koden kun forberedelse, ledninger, skrivning af konfigurationer og andre kedelige ting. Men virkelig nyttig kode, der udfører det faktiske arbejde, fylder 2 dusin linjer.

Men på den anden side tillod konfigurationerne os at skabe en struktur, der let kan udvides, når der tilføjes nye sider. Plus, i den næste artikel vil vi se vigtigheden af ​​denne ret store konfiguration, når vi lærer søgemaskiner at indeksere vores en-sides hjemmeside. Nå, der skal stile til for at få det til at se smukkere ud :-)

Der er også en tredjepart. For dem, der ikke er bekendt med en-sides websteder, er dette slet ikke en simpel ting. Og jeg synes, det er dejligt, når et til at begynde med tilsyneladende komplekst emne, efter detaljeret overvejelse, viser sig at være fuldstændigt løseligt, og uden den store indsats fra vores side.

Dernæst vil vores demoside gradvist udvikle sig. I den næste artikel vil vi begynde at forberede webstedet til indeksering af søgemaskiner, fordi det er kendt, at enkeltsidede websteder indekseres meget dårligt, hvis der ikke tages særlige handlinger. Men dette er fra de næste artikler i serien.

Og en lille undersøgelse

I dag vil jeg gerne beskrive mit syn på udvikling webapplikationer(eller enkelt side ansøgning). En webapplikation er en hjemmeside, hvis drift overføres så fuldstændigt som muligt til klientsiden. En sådan hjemmeside "kommunikerer" kun med serveren med rene data, uden at indlæse html-indhold. Alle knapper, formularer osv. behandles javascript'om, alle lister, tabeller, blokke og andre sideelementer gengives ved hjælp af JavaScript, når de ændres. Det vil sige, at serveren kun sender data, normalt ind json-format, og klientsiden genererer uafhængigt webstedssiden, alle skabeloner, lister, links, tabeller og andre opdaterede elementer.

Grundlæggende regler for applikation på én side

1. Alle entiteter i en webapplikation er baseret på modeller og objekter (arbejde med DOM-elementer på siden er indkapslet inde i objekterne).
2. HTML-skabeloner gemmes i scripts (i det omfang det er muligt).
3. Eventuelle ændringer på siden.
4. Direkte indlæsning af enhver url skulle vise den tilsvarende dataside.
5. Historie tilbage (tilbage-knap i browseren) skal behandles korrekt og returnere siden til den forrige tilstand.
6. Caching af datamodeller på klientsiden.

Ovenstående punkter er fra mit synspunkt de vigtigste. For at optimere arbejdet, eller for at undgå at komplicere systemet, skal der selvfølgelig ofres noget.

Rækkefølgen af ​​arbejdet med webapplikationen

1. Indekssiden er blevet indlæst (skabelonen vises fuldt ud og er fyldt med data).
   1. Alle nødvendige objekter er blevet initialiseret, og alle hændelseslyttere er blevet installeret.
2. Brugeren klikker på et link/knap/et hvilket som helst interaktivt element.
3. Applikationen opsnapper klikhændelsen.
4. Hvis klik på et objekt indebærer en ændring i webapplikationens tilstand ->
5. Vi danner en ny URI for den nye sidetilstand.
6. Skift den aktuelle uri vha javascript (skift uri uden at genindlæse siden).
7. En begivenhed opsnappes URI ændringer.
8. Vi analyserer vores nye adresse og får alle nøgleværdierne.
9. Lad os tjekke, hvad der er ændret i tasterne.
10. Vi sender en anmodning til serveren om at modtage nye data.
11. Vi accepterer svaret og kalder tilbagekaldsfunktionen for vellykket dataindlæsning.
12. Tegn de nødvendige dele af siden igen.

Med denne rækkefølge opstår der et spørgsmål vedrørende punkt 5-10 (og en anmodning om data), hvorfor ikke straks anmode om data ved adresseændring? Svaret er enkelt: Vi opretter et indgangspunkt til at håndtere uri-ændringen, og et indgangspunkt til at håndtere den nye adresse og anmodningsdata. Hvis du gør dette hver gang i et dusin metoder, vil det være dårlig kode, da der vil være meget copy-paste. På ovenstående måde vil der være to indgangssteder og som følge heraf ekspansionspunkter for disse strækninger webapplikationer.

Implementering af en enkeltsideapplikation

Til sidst, brug sekvensen / klik på det aktive element -> skift uri -> bearbejd den nye uri -> anmod om data -> gengiv nye sideelementer / du kan oprette fuldt funktionelle enkeltside applikationer. I mit arbejde brugte jeg , og fordelte næsten alt i klasser, som hver kontrollerede sit eget område.

Den vigtigste er skabt javascript initialiseringsfil, som starter applikationen. Hovedklassen oprettes også (f.eks. enkelt applikation), som styrer applikationens tilstand, initialiserer de nødvendige hændelser, arbejder med historie objekt, behandler og ændrer url og andre funktioner. URL'en genereres med SEO-understøttelse (/category/tech/page/2) ved hjælp af /key/value/-konceptet. I min applikation brugte jeg også , som gjorde det muligt for mig at reducere antallet af fejl, minimere klassesammenhæng og gøre det lettere at arbejde med tilbagekaldsfunktioner, som jeg byggede på enkelt side ansøgning.