En enkeltsideapplikasjon ( SPA ), eller enkeltsideapplikasjon, er en nettapplikasjon eller et nettsted som passer på en enkelt side med det formål å gi brukerne en mer flytende opplevelse, som om det var en skrivebordsapplikasjon. I et SPA lastes all HTML , JavaScript og CSS én gang [ 1 ] eller de nødvendige ressursene lastes dynamisk når det kreves av siden, vanligvis som svar på brukerhandlinger. Siden trenger ikke lastes på nytt på noe tidspunkt i prosessen, og det er heller ikke nødvendig å overføre til en annen side, selv om moderne teknologier (som HTML5 API pushState()) tillater navigering på logiske sider i applikasjonen. Interaksjon med enkeltsideapplikasjoner kan innebære dynamisk kommunikasjon med den underliggende webserveren.
Begrepet enkeltsideapplikasjon ble brukt av Steve Yen i 2005, selv om konseptet allerede hadde blitt diskutert i 2003. [ 2 ] Stuart Morris skrev et enkeltsides nettsted slashdotslash.com som hadde de samme målene og funksjonene i 2002 [ 3 ] Samme år beskrev Lucas Birdeau, Kevin Hakman, Michael Peachey og Evan Yeh implementeringer av enkeltsideapplikasjoner i US patent 8,136,109. [ 4 ]
Moderne nettlesere som kan analysere HTML5 lar utviklere skifte brukergrensesnitt og applikasjonslogikk fra servere til klienter. Åpen kildekode-biblioteker støtter opprettelsen av et SPA uten å tvinge utvikleren til å gå dypt inn i JavaScript og slite med teknologiproblemer.
Det er flere tilgjengelige teknikker som kan få nettleseren til å beholde en applikasjon som krever kommunikasjon med serveren på en enkelt side.
JavaScript-rammeverk for nettlesere som AngularJS , Ember.js , Meteor.js , ExtJS og React har alle vedtatt SPA-prinsipper.
Den mest fremtredende teknikken som brukes er Ajax. [ 1 ] Bruken av XMLHttpRequest JavaScript- objektet dominerer , andre applikasjoner av AJAX inkluderer bruk av IFRAME- eller HTML-skriptelementer. Populære biblioteker som jQuery normaliserer AJAX-adferd på tvers av forskjellige nettlesere og produsenter, noe som gjør AJAX mer populær.
WebSockets er sanntidskommunikasjonsteknologi mellom klient og server og er en del av HTML5-spesifikasjonen. Den er overlegen AJAX når det gjelder ytelse og enkelhet. [ 7 ]
Selv om denne metoden er gammel, kan asynkrone anrop til serveren også oppnås ved å bruke nettleserplugin-teknologier som Silverlight , Flash eller Java-appleter .
Forespørsler til serverne resulterer vanligvis i at rådata ( XML eller JSON ) eller ny HTML returneres. I tilfeller der HTML returnerer som et resultat, oppdaterer JavaScript på klienten det delvise området av DOM ( Document Object Model ). Når rådataene returneres, behandler JavaScript på klientsiden XML eller JSON for å gjøre oversettelsen av rådataene til HTML som brukes til å oppdatere informasjonen i delområdet av DOM.
En SPA flytter logisk fra serveren til klienten. Dette resulterer i at rollen til webserveren utvikler seg til en webtjeneste eller data-API. Denne arkitekturendringen har blitt kalt "Thin Server Architecture" for å understreke at kompleksiteten er flyttet fra serveren til klientene, med den begrunnelse at dette reduserer kompleksiteten i systemet.
Statlig serverarkitekturServeren holder styr på tilstanden til klientene på siden. På denne måten, når en forespørsel kommer til serveren, sender serverne riktig HTML og med de spesifikke endringene til klientene slik at de kan gå over til den tilsvarende tilstanden (normalt legge til/slette/oppdatere en del av klientens DOM). Samtidig oppdateres tilstandsserveren. Det meste av logikken utføres på serveren, og HTML-en blir også behandlet på serveren. I noen tilfeller simulerer serveren nettleseren, mottar hendelser og gjør deltaendringer i servertilstanden som automatisk overføres til klienten.
Denne tilnærmingen trenger mer serverminne og serverbehandling, men fordelen er at utviklingsmodellen er enkel fordi a) applikasjonen er fullstendig kodet på serveren, og b) dataene og tilstanden på serveren er lagret på selve serveren. plass uten behov for kommunikasjonsbroer mellom serveren og klienten.
Tung statsløs serverarkitekturDet er varianten av tilstandsserveren. I dette tilfellet sender klienten dataene som representerer tilstanden til serveren, vanligvis gjennom AJAX-forespørsler. Ved å bruke disse dataene kan serveren rekonstruere klientens tilstand og bestemme hvilken del av siden som må endres, generere den med de nødvendige dataene som sendes tilbake til klienten slik at den kan gå over til en annen tilstand, og endre treet til DOM basert på handlingen til klienten som utløste forespørselen.
Denne tilnærmingen krever at mer informasjon sendes til serveren og kan kreve flere beregningsressurser per forespørsel for å delvis eller fullstendig rekonstruere klientens side på serveren. Samtidig er denne tilnærmingen mer skalerbar fordi det ikke er noen klientsider som er lagret på serveren, så AJAX-forespørsler kan overføres til en annen servernode uten behov for å dele øktdata.
Noen SPA-er kan kjøres ved å bruke de lokale filene gjennom URI-skjemaet. Dette lar brukere laste ned en SPA fra serveren og kjøre filen fra lokal lagring, uten å måtte stole på tilkobling til serveren. Hvis noen SPA krever lagring og oppdatering av data, må den bruke nettlagring, som er basert på nettlesere; Disse applikasjonene har dratt nytte av utviklingen av HTML5 med hensyn til det. [ 8 ]
Siden SPA er en evolusjon bort fra "stateless page-redraw"-modellen som nettlesere ble designet på, har det dukket opp noen endringer. Hvert av disse problemene har en effektiv løsning [ 9 ] med:
På grunn av mangelen på JavaScript-kjøring i populære søkemotorsøkeprogrammer [ 14 ] [ 15 ] SEO ( Søkemotoroptimalisering ) har hatt problemer for offentlige sider som tok i bruk SPA-modellen. [ 16 ]
Google gjennomsøker nettadresser som inneholder hash-fragmenter som begynner med #!. [ 17 ] Dette tillater bruk av hash-fragmenter innenfor en enkelt SPA-URL. Spesiell atferd må implementeres av SPA-nettstedet for å tillate utvinning av relevante metadata for søkemotoren. For noen søkemotorer som ikke støtter URL-hash-ordningen, forblir SPA-hash-nettadresser usynlige.
Alternativt kan applikasjoner behandle den første siden under lasting på serveren og påfølgende oppdateringer på klienten. Dette er tradisjonelt vanskelig, fordi gjengivelseskoden kanskje må skrives på et annet språk eller rammeverk på serveren og klienten. Bruk av maler uten logikk eller bruk av krysskompilering fra ett språk til et annet, eller bruk av samme språk på serveren og klienten kan bidra til å øke mengden kode som kan deles.
Siden SEO-støtte er ikke-triviell i SPA-er, er det ikke hensiktsmessig å bruke SPA-er i sammenhenger hvor indeksering for søkemotorer er et krav. Brukstilfeller inkluderer applikasjoner som håndterer private data skjult bak et autentiseringssystem. I tilfeller hvor disse applikasjonene er forbrukerprodukter, brukes modeller som «page redraw» som på annonsesider der nok metadata av applikasjonen vises i søkemotoren. Blogger, støttefora og andre gjenstander for gjentegning samles også rundt SPA-et der motorer kan søke etter relevante termer.
En annen tilnærming brukt av serversentriske rammeverksservere som ItsNat som er basert på Java for å gjengi hypertekster på serveren ved å bruke samme språk og malteknologi. I tilnærmingen kjenner serveren nøyaktig DOM-tilstanden til klienten, og eventuelle nødvendige endringer eller oppdateringer genereres på serveren og transporteres deretter av AJAX, samme JavaScript endrer tilstand til klienten ved å utføre DOM-metodene. Utviklere kan bestemme hvilke sidetilstander som kan leses av søkeroboten for SEO, og bør kunne generere den nødvendige tilstanden ved lastetid og i HTML i stedet for JavaScript. I ItsNat-tilfeller er dette automatisk siden ItsNat opprettholder klientens DOM-tre på serveren som Javas W3C DOM; og behandling av treet på serveren genererer vanlig HTML ved lastetid og DOM-ene for AJAX-forespørsler. Denne dualiteten er veldig viktig for SEO fordi utviklere kan bygge med samme Java-kode og HTML-baserte maler på serveren; ved lastetid genereres vanlig HTML av ItsNat, noe som gjør DOM SEO-vennlig. Siden versjon 1.3 har [ 18 ] ItsNat tilbyr en tilstandsløs modus, der klient-DOM ikke er lagret på serveren, siden i den modusen blir tilstanden DOM delvis eller fullstendig gjenoppbygd på serveren når forespørsler behandles. AJAX ber om og krever klienten skal sende de fullstendige DOM-dataene for sin tilstand; statsløs modus kan også være SEO-vennlig fordi støtten skjer ved første sideinnlastingstid uten å bli påvirket av tilstandsmoduser.
Det finnes flere alternativer for å gjøre siden gjennomsøkbar. De involverer opprettelsen av separate HTML-sider som speiler SPA-innholdet. Serveren kan lage en HTML-basert versjon av nettstedet og levere den til robotsøkeprogrammer, eller det er også mulig å bruke en hodeløs nettleser som PhantomJS for å kjøre JavaScript-applikasjoner og vise resultatet i HTML.
Begge teknikkene krever manuelt arbeid og kan ende opp som en hodepine for vedlikehold av komplekse sider. Det er også flere SEO fallgruver. hvis den genererte HTML-en fra serveren er veldig forskjellig fra SPA-en til innholdet, vil siden bli straffet. Å kjøre PhantomJS for å vise HTML kan redusere responshastigheten til sidene som søkemotorer, spesielt Google, senker rangeringene dine. [ 19 ]
En måte å øke mengden kode som må deles mellom servere og klienter er å bruke logikkløse maler som Moustache eller Handlebars . Disse malene kan tolkes på forskjellige språk, som Ruby på serveren og JavaScript på klienten, men deling av malene krever duplisering av forretningslogikken som brukes til å velge de riktige malene og fylle dem med data. Å tolke disse malene kan påvirke ytelsen negativt når bare en liten del av siden oppdateres, samt en veldig stor tekstinndataverdi i en mal. Å erstatte en hel mal kan også rote med brukerens valg eller markørposisjon, mens bare å oppdatere dataene ikke ville gjøre det. For å unngå disse problemene bruker applikasjoner databinding eller granulær DOM-manipulasjon for kun å oppdatere de riktige delene av siden i stedet for å tegne hele malen på nytt.
Etter SPAs egen definisjon bryter en enkeltsideapplikasjon utformingen av nettlesere som bruker tilbake/frem-knapper. Dette presenterer et brukervennlighetshinder når brukeren trykker tilbake-knappen, de ville ventet forrige SPA-skjerm, men ville i stedet åpne den forrige siden de fikk tilgang til før de gikk inn i SPA-applikasjonen.
Den tradisjonelle løsningen for SPA har vært å endre nettleserens URL med hashen som identifiserer fragmentet i henhold til gjeldende tilstand på skjermen. Dette kan oppnås gjennom JavaScript, og fører til at hendelser bygges inn i nettleserens URL-historikk. Så lenge SPA er i stand til å tegne den samme skjermen på nytt med informasjonen i URL-hashen, opprettholdes den forventede oppførselen.
For å løse dette på en annen måte, introduserte HTML5-spesifikasjonene pushState og replaceState- metoder som gir programmatisk tilgang til gjeldende URL og nettleserhistorikk.
Analyseverktøy som Google Analytics er avhengig av sider som lastes inn i en nettleser som utløses av en URL-endring. I et SPA, etter at den første siden er lastet, håndterer applikasjonen internt alle påfølgende sider og innholdsendringer, slik at nettleseren aldri utløser en full reload av siden, og det legges heller ikke til oppføringer i loggen til nettleseren. Det er derfor det aktuelle analyseverktøyet ikke aner hvem som gjør hva på den siden.
Legg til sideinnlastinger i et SPALastehendelser kan legges til et SPA-nettsted ved å bruke HTML5s historiefunksjoner; dette hjelper med å integrere analyser. Vanskeligheten er å administrere dem og sikre at alt spores nøyaktig. Dette innebærer å sjekke for manglende rapporter og doble oppføringer. Den gode nyheten er at det ikke er nødvendig å bygge alt fra bunnen av. Det er flere åpen kildekode-analyseintegrasjoner for Angular som er tilgjengelige på nettet, og finner de fleste analyseleverandører. Utviklere må integrere dem i appen og sørge for at alt fungerer som det skal, men det er ikke nødvendig å starte alt fra bunnen av. [ 19 ]
SPA-er har en lavere lastehastighet enn serverbaserte applikasjoner. Dette er fordi den første nedlastingen må hente alle rammeverkene og applikasjonskoden før du tegner det som kreves for HTML-nettleseren. En serverbasert applikasjon trenger bare å sende nødvendig HTML til nettleseren, noe som reduserer ventetiden og nedlastingstiden.
Øke starthastighetenDet er flere måter å øke hastigheten på et SPA på, samt moduler som laster ned moduler som laster dem ned når det trengs. Men du kommer ikke unna det faktum at SPA-er må laste ned rammeverkene, applikasjonskoden og sannsynligvis API for dataene før de viser noe i nettleseren. [ 19 ] Dette er litt av et "betal meg nå eller betal meg senere"-scenario. Spørsmålet om ytelse og ventetid forblir opp til utbyggers avgjørelse.
En SPA er fulllastet under den første sideinnlastingen, og deretter erstattes eller oppdateres regionene med de nye sidefragmentene etter forespørsel fra serveren. For å unngå overdreven nedlasting av ubrukte funksjoner, laster en SPA gradvis ned funksjoner etter hvert som de er nødvendige, disse kan være sidefragmenter eller hele skjermmoduler.
På denne måten er det en analogi mellom "statene" til et SPA og "sidene" til et tradisjonelt nettsted. Siden navigering av stater på samme side er analog med navigering av sider, kan en hvilken som helst nettside i teorien konverteres til en enkeltsideside ved å erstatte sider bare der de forårsaker en endring. SPAs tilnærming til nettsiden ligner på Single Document Interface (SDI), som er en teknikk for skrivebordsapplikasjoner.