Mida peate suutma teha ühelehelises rakenduses. Üheleheline rakendus

• Õpetus

Ühelehelistel rakendustel (SPA) on palju eeliseid, nagu kiirus, väga hea kasutajakogemus ja täielik kontroll HTML-i märgistuse üle. SPA-alasid on järjest rohkem; Üha rohkem on tööriistu, mis SPA arendusprotsessi lihtsustavad. Tõenäoliselt olete juba lugenud noore ja paljutõotava raamistiku Vue.js kohta. Soovitan teil sukelduda Vuesse sügavamale ja kasutada konkreetset näidet lihtsa SPA mõistmiseks.

Kirjutame lihtsa ajaveebi jaoks klient-serveri rakenduse. Rakendus kuvab nii kirjete loendi kui ka iga üksiku kirje täisteksti. Ja loomulikult toimub see kõik ilma lehte uuesti laadimata.

Pärast selle näidisrakenduse lugemist saate teada, kuidas Vues andmeid ekstraheerida, marsruute luua ja mõista Vue huvitavat funktsiooni – ühefaililisi komponente.

Nii et kõigepealt installime vue-cli globaalse paketina:

$ npm install -g vue-cli
Seejärel lähtestame projekti valitud malliga; Meie näiteks on webpack-lihtsuse kasutamine enam kui piisav.

$ vue init webpack-simple vue-spa
Järgmisena minge vue-spa kausta ja käivitage npm installimine terminalis. Pärast kõigi pakettide installimist saame oma rakenduse käivitada arendusrežiimis.

$ npm käivita dev
See käsk käivitab meie projekti automaatselt kohalikus veebipaketi arendajaserveris. Meie lihtsaim Vue rakendus kuvatakse brauseris. Muidugi ei näe see sugugi selline, nagu me tahaksime ja sobib vaid lähtepunktiks millegi suurema alustamiseks. Töö jätkamiseks soovitan teil esmalt tutvuda meie malli ülesehitusega.

Sisemiselt on veebipaketi lihtsal mallil järgmine struktuur:

Fail index.html sisaldab lihtsat HTML-i märgistust, mille kehas on üks "rakenduse" element. See asendatakse vue loodud DOM-iga. Sel põhjusel silt keha Ei ole soovitatav kasutada juurelemendina.

Kaustas src peitub fail main.js, mis sisaldab veebipaketi sisenemispunkti. Sinna imporditakse Vue komponente. See kirjeldab ka Vue juureksemplari, millel on seni kaks omadust. Atribuut „el” pakub Vue eksemplari seosega määratud DOM-i elemendiga. Teine on renderdusfunktsioon, mis genereerib DOM-i App.vue. Kokkuvõttes on see kõik, mida me peame veebipaketi lihtsa mallistruktuuri kohta teadma, mitte palju, eks? Meie rakenduse põhiosa programmeeritakse rakenduses App.vue. Laiend .vue tuvastab faili ühe faili vue komponendina. See on üks Vue funktsioone, mida me nüüd lähemalt uurime.

Iga *.vue-fail koosneb kolme tüüpi plokkidest: , ja valikuliselt . Selle tulemusena saame projekti jagada seotud komponentideks. Komponendi sees on selle mall, loogika ja stiilid olemuslikult seotud ning nende kombineerimine muudab komponendi tegelikult sidusamaks ja hõlpsamini hooldatavaks. Nüüd oleme valmis Vues blogi looma.

Vaatame, mida me tegelikult rakendame. Meie ajaveebi nimega päis on lehe ülaosas. Vasakul küljel on fikseeritud külgriba, kus kuvame oma postituste pealkirjad, see on midagi sisukorra taolist. Ülejäänud lehe hõivab dünaamiline plokk, milles kuvatakse postituse tekst ise.

Vue.js SPA
Teiseks loome andmete atribuudiga Vue eksemplari, mille paigutame oma sõnumitega massiivi. Hetkel on see tühi, kuid peagi paneme serverist saadud andmed massiivi sisse.

Pärast esimest kõnet ei saa te enam juurandmeobjektile reaktiivseid omadusi lisada. Seetõttu on enne Vue eksemplari loomist soovitatav deklareerida kõik reaktiivsed omadused juurtasemel.

ekspordi vaikimisi(andmed()(return(postitused:)))
Rakenduse paremaks väljanägemiseks saate lisada ka stiili.
Rakenduse kood asub saidil github.com. Piisab hoidla kloonimisest ja haru sammude kaupa vahetamisest, et jälgida rakenduse arengut samm-sammult, näiteks:

$ git checkout samm-1
Meil pole praegu oma navigeerimisribal absoluutselt midagi kuvada, nii et hangime andmed serverist. Selleks valisin lihtsalt kasutatava HTTP kliendi Axiose. Võite kasutada ka mis tahes teile meeldivat meetodit, näiteks Vue ressurssi või kohandatud toomist või isegi jQuery Ajaxi.

$ npm install --save-dev axios
Seejärel impordime selle rakenduse komponenti ja määratleme meetodi getAllPosts(), mis esitab serverile päringu ja määrab selle atribuudile postitused. Me kutsume meetodi loodud() konksus, mida kutsutakse välja pärast Vue eksemplari loomist ja andmetele juurdepääsu seadete seadistamist.

Impordi aksiosid "axiost" ekspordi vaikeväärtusega ( andmed () ( tagastamine ( postitused: null, lõpp-punkt: "https://jsonplaceholder.typicode.com/posts/", ) ), loodud() ( this.getAllPosts(); ) , meetodid: ( getAllPosts() ( axios.get(this.endpoint) .then(response => ( this.posts = response.data; )) .catch(error => ( console.log("----- viga-------"); console.log(error); )) ) ) )
Nüüd kuvame külgribal kõik postituste pealkirjad.

((post.title))
Seni oleme kuvanud ainult postituste pealkirju, kuid postitusi endid me veel ei näe. Nüüd peate kuvama kogu postituse sisu jaotises vastavalt külgribal valitud pealkirjale. Samas soovin, et iga plaat oleks saadaval oma unikaalsel aadressil.

$ npm install --save-dev vue-ruuter
Marsruutimise konfigureerimiseks pöördume tagasi faili main.js juurde. Siin määratleme marsruutimise sätted ja lisame need meie Vue eksemplari.

Importige Vue kohast "vue" importige ruuter "vue-ruuterist" importige rakendus rakendusest "./App.vue" importige postitus väljast "./components/Post.vue" importige tere saidist "./components/Hello.vue" Vue. use(Router) const ruuter = new Ruuter(( marsruudid: [ ( tee: "/", nimi: "kodu", komponent: Tere, ), ( tee: "/post/:id", nimi: "postitus", komponent: postitus, rekvisiidid: tõsi, ] )) new Vue(( el: "#app", renderda: h => h(App), ruuter ))
Marsruutimise seadetes määrasime, milline komponent põhjustab renderdamise vastaval teel. Kuna iga postituse renderdamise eest vastutab ainult komponent Post.vue, ei pea me määratlema iga postituse teed, vaid lihtsalt määratlema dünaamilise tee.

Tee: "/post/:id"
See tee sisaldab dünaamilist segment:id, mis osutab konkreetsele postitusele. Lisaks on meil sellele segmendile juurdepääs komponendis Post kaudu this.$route.params.id. Kuid $route kasutamine meie komponendis ühendab selle marsruudiga, mis omakorda piirab komponendi paindlikkust, kuna seda saab kasutada ainult teatud URL-idel. Selle asemel saame kasutada valikut rekvisiidid ja installige see sisse tõsi. Pärast seda seostatakse $route.params komponendi Postitus suvandiga props.
Nüüd, kui oleme ruuteri loonud, saame naasta oma rakenduse juurde ja lisada mallile veel paar rida.

((post.id)). ((post.title))
Siin on meil kaks komponenti vue-ruuter: Ja. Esimene neist on komponent, mis võimaldab kasutajal navigeerida marsruutimist võimaldavas rakenduses. Teine komponent on funktsionaalne komponent, mis muudab antud tee jaoks ühtse komponendi.

Viimane samm jääb alles. Peame kuvama postituse sisu.

((post.body))

((post.id))

Impordi aksiosid "aksiodest"; ekspordi vaikeseade ( props: ["id"], data() ( return ( post: null, endpoint: "https://jsonplaceholder.typicode.com/posts/", ) ))
Seejärel kirjeldame meetodit getPost(), mis saab ainult ühe postituse sissekande id-ga ja kutsuge seda konksu loodud().

Meetodid: ( getPost(id) ( axios(this.endpoint + id) .then(response => ( this.post = response.data )) .catch(error => ( console.log(error) )) ) ), loodud() ( this.getPost(this.id); ),
Peaaegu valmis. Kui käivitame rakenduse praegu, näeme, et kuigi URL muutub, näeme üksikut postitust, mis renderdati esimesena. Asi on selles, et meil on erinevate postituste renderdamiseks sama komponent ja Vue ei pea seda tarbetu ressursside raiskamise tõttu uuesti looma, mis tähendab ka seda, et komponendi elutsükli konksud ei kutsuta välja.
Selle parandamiseks peame lihtsalt objektile seadma jälgija $marsruut.

Vaata: ( "$route"() ( this.getPost(this.id); ) )
Nüüd töötab kõik nii nagu peab. Tootmisversiooni hankimiseks käivitage lihtsalt käsk npm run build konsoolis.

Ühelehelised rakendused

See ja järgnevad artiklid kirjeldavad Web API tööriista, mis on suhteliselt uus lisand ASP.NET platvormile, mis võimaldab teil kiiresti ja lihtsalt luua veebiteenuseid, mis avavad API HTTP-klientidele.

Veebi API tööriist põhineb samal alusel nagu ASP.NET MVC Frameworki rakendused, kuid ei kuulu ASP.NET MVC Frameworki. Selle asemel võttis Microsoft nimeruumist System.Web.Mvc võtmeklassid ja nendega seotud omadused ning dubleeris selle nimeruumi System.Web.Http.

Idee seisneb selles, et veebi API on osa peamisest ASP.NET raamistikust ja seda saab kasutada muud tüüpi veebirakendustes või eraldiseisva veebiteenuste mootorina. Veebi API tööriista üks peamisi kasutusviise on üheleheliste rakenduste (SPA) loomine, kombineerides veebi API ja ASP.NET MVC Frameworki võimalustega. Järgmisena näitame teile, mis on SPA rakendused ja kuidas need töötavad.

Veebiteenuste loomise lihtsustamine on veebi API lahutamatu funktsioon. See on märkimisväärne edasiminek võrreldes teiste veebiteenuste tehnoloogiatega, mida Microsoft on viimase kümnendi jooksul pakkunud. Mulle meeldib Web API tööriist ja peaksite seda oma projektides kasutama, muu hulgas seetõttu, et see on lihtne ja tugineb samale disainifilosoofiale nagu ASP.NET MVC Framework.

Üsna laialdaselt kasutatakse terminit üheleheline rakendus (SPA). Kõige järjekindlam määratlus on see, et tegemist on veebirakendusega, mille esialgne sisu edastatakse HTML-märgistuse ja JavaScripti koodi kombinatsioonina ning järgnevad toimingud tehakse veebiteenuse REST abil, mis edastab vastuseks Ajaxi päringutele andmeid JSON-vormingus.

See erineb eelmistes näidetes ehitatud rakendustest, kus kasutaja toimingute tulemuseks olid uued HTML-dokumendid, mis genereeriti vastuseks sünkroonsetele HTTP-päringutele. Selliseid taotlusi hakatakse nimetama edasi-tagasi taotlusteks (RTA).

SPA rakenduse eelised on, et see nõuab vähem ribalaiust ja kasutaja saab sujuvama liidese. Puuduste hulka kuulub see, et seda elegantsemat liidest võib olla raske saavutada ning SPA-rakenduse jaoks vajaliku JavaScripti koodi keerukus tähendab, et on vaja hoolikat kavandamist ja testimist.

Enamik rakendusi kombineerivad SPA- ja RTA-tehnikaid, kusjuures iga peamine rakenduste funktsionaalsuse valdkond tarnitakse SPA-na ja navigeerimine funktsionaalsuspiirkondade vahel, mida hallatakse standardsete HTTP-päringute abil, mis loovad uue HTML-dokumendi.

Nende artiklite jaoks luuakse Visual Studios malli Empty kasutades uus MVC projekt nimega WebServices. Jaotises Lisa kaustu ja põhiviiteid on märgitud ruudud MVC ja Web API, nagu on näidatud alloleval pildil:

Seda projekti kasutatakse tavalise ASP.NET MVC Frameworki rakenduse loomiseks ja seejärel veebiteenuse loomiseks veebi API abil. Kui veebiteenus on valmis, muudetakse ASP.NET MVC Frameworki rakendus üheleheliseks rakenduseks.

Rakendus loob ja haldab tubade broneerimise taotluste komplekti. Rakendus on kavas hoida lihtsana, et saaksite keskenduda kirjeldatava objekti mehaanikale, seega koosnevad broneerimissoovid ainult kliendi nimest ja ruumi asukohast. Kausta Models on lisatud klassi fail nimega Reservation.cs, mille sisu on näidatud allolevas näites:

Nimeruum WebServices.Models ( public class Reservation ( public int ReservationId ( get; set; ) public string ClientName ( get; set; ) public string Location ( get; set; ) ) )

Plaan on luua lihtne mälusisene broneerimisobjektide kogu, mis toimiks andmehoidlana. Andmebaasi pole vaja installida, kuid peate suutma teha CRUD-operatsioone mudeliobjektide kogumiga, et demonstreerida Web API mõningaid olulisi aspekte. Klassifail nimega ReservationRepository.cs lisatakse ka kausta Models:

Kasutades System.Collections.Generic; kasutades System.Linq; nimeruum WebServices.Models ( public class ReservationRepository ( privaatne staatiline ReservationRepository repo = new ReservationRepository(); public static ReservationRepository Current ( get ( return repo; ) ) private List data = new List ( new Reservation ( ReservationId = 1, ClientName) , Asukoht = "Hotell"), uus broneering (ReservationId = 2, ClientName = "Vasya", Location = "Library"), uus broneering (ReservationId = 3, ClientName = "Igor", Location = "Söögituba"), ) ; public IEnumerable GetAll() ( tagastavad andmed; ) public Reservation Get(int id) ( return data.Where(r => r.ReservationId == id).FirstOrDefault(); ) public Reservation Add(Reservation item) ( item. ReservationId = data.Count + 1; Add(item return item ) public void Remove(int id) ( Reservation item = Get(id); if (item != null) ( data.Remove(item); ) ) public bool Update(Reserveerimisüksus) ( Broneering storedItem = Get(item.ReservationId); if (salvestatud üksus != null) ( storedItem.ClientName = item.ClientName; storedItem.Location = item.Location; tagasta tõene; ) muidu ( tagasta vale; ) ) )

Reaalses projektis peaksime hoolitsema klassidevahelise tiheda sideme katkestamise ja rakendusse liideste sisseviimise ning sõltuvuse süstimise eest. See teema keskendub aga ainult veebi API-dele ja SPA-rakendustele, nii et standardsete tavade osas tehakse mõningaid lihtsustusi.

Salvestusklassil on esialgne loend kolmest reserveerimisobjektist ja see määrab meetodid, mis võimaldavad teil kollektsiooni vaadata, lisada, kustutada ja värskendada. Kuna poes puudub püsivus, lähevad rakenduse peatamisel ja taaskäivitamisel kõik poes tehtud muudatused kaotsi, kuid see näide keskendub täielikult sisu edastamisviisile, mitte sellele, kuidas seda serveris salvestatakse. Päringute vahel teatud püsivuse tagamiseks luuakse klassi ReservationRepository eksemplar, millele pääseb juurde staatilise atribuudi Current kaudu.

See ja järgnevad artiklid kasutavad kolme NuGeti paketti: jQuery, Bootstrap ja Knockout. JQuery ja Bootstrapi teeke on juba varem kirjeldatud ja kasutatud. Knockout on teek, mille Microsoft on kohandanud üheleheliste rakenduste jaoks. Selle lõi Steve Sanderson. Kuigi Steve töötab Microsofti heaks, on Knockouti pakett Knockouti raamatukogu veebisaidil avatud lähtekoodiga saadaval ja seda on laialdaselt kasutusele võetud. Näitame teile hiljem, kuidas Knockout töötab, kuid praegu peate installima ülalmainitud paketid.

NuGeti käsurea akna avamiseks valige Tööriistad --> Library Package Manager --> Package Manager Console ja sisestage järgmised käsud:

Install-Package jquery -versioon 1.10.2 -projekti nimi WebServices Install-Package bootstrap -versioon 3.0.0 -projekti nimi WebServices Install-Package knockoutjs -versioon 3.0.0 -projektinimi WebServices

Näidisprojektile on lisatud kontroller nimega Home, mille definitsiooni näeb näites:

WebServices.Modelsi kasutamine; kasutades System.Web.Mvc; nimeruum WebServices.Controllers ( avalik klass HomeController: Controller ( ReservationRepository repository = ReservationRepository.Current; public ViewResult Index() ( return View(repository.GetAll()); ) public ActionResult Add(Reservation item) (Is (ModelValid) (Is (ModelValid). repository.Add(item) return RedirectToAction("Indeks" ) else return View("Indeks" ) public ActionResult Update(Reservation item) ( if (ModelState.IsValid && repository.Update(item)) return RedirectToAction(); "Indeks"); muidu tagastab vaade("Indeks" ) )

See on nii lihtsa rakenduse jaoks täiesti tüüpiline kontroller. Iga tegevusmeetod vastab otseselt ühele poes leiduvatest meetoditest. Kontrolleri ainus kasulikkus tuleneb mudeli valideerimisest, vaadete valimisest ja ümbersuunamisest. Muidugi oleks reaalses projektis täiendav domeeniloogika, kuid kuna näidisrakendus on nii elementaarne, on kontroller lõpuks midagi enamat kui lihtne ümbris poe ümber.

Rakenduse jaoks sisu genereerimiseks luuakse kaust Views/Shared ja sellele lisatakse vaatefail nimega _Layout.cshtml, mille sisu on näidatud allolevas näites:

@ViewBag.Title @RenderSection("Skriptid") @RenderSection("Keha")

See põhipaigutus pakub elemente Bootstrapi teegi CSS-failide jaoks. Paigutus määratleb kaks jaotist, skriptid ja keha, mida kasutatakse paigutusse sisu sisestamiseks. Järgmine samm on rakenduse jaoks tipptaseme vaate loomine. Kuigi järgmine samm on tavalise ASP.NET MVC Frameworki rakenduse loomine, teate, et lõpuks loote ühe lehe rakenduse.

Teisendust on lihtsam teha, kui loote ühe vaate, mis sisaldab kogu rakenduse jaoks vajalikku HTML-i märgistust, isegi kui tulemus tundub esialgu pisut kummaline. Vaatefail nimega Index.cshtml lisatakse kausta Views/Home, mille sisu on näidatud allolevas näites:

@using WebServices.Models @mudel IEnumerable @( ViewBag.Title = "Reservations"; } @section Scripts { } @section Body { @Html.Partial("Summary", Model) @Html.Partial("Editor", new Reservation()) }!}

Selle vaate vaatemudel kujutab endast reserveerimisobjektide loendit ja kasutajale kuvatavate funktsioonide ehitusplokkide pakkumiseks luuakse kaks osavaadet. Esimese osavaatega faili nimi on Summary.cshtml. See fail luuakse kaustas Views/Home:

@mudel IEnumerable Kõik tellimused

Osalise vaate vaatemudel on sama reserveerimisobjektide loend ja seda kasutatakse stiiliga tabeli genereerimiseks kasutades elemendina Bootstrapi

Teine osaline vaade kannab nime Editor.cshtml ja asub samuti kaustas Views/Home. Selle faili sisu on näidatud allolevas näites. Osavaade sisaldab vormi, mida kasutatakse uute broneerimistaotluste loomiseks. Vormi esitamine kutsub esile kodukontrolleri toimingu Lisa.

@model WebServices.Models.Reservation Loo tellimus @kasutades (Html.BeginForm("Add", "Home")) ( Kliendi nimi @Html.TextBoxFor(m => m.ClientName, new ( @class = "form-control") )) Paigutus @Html.TextBoxFor(m => m.Location, new ( @class = "form-control" )) Salvesta )

Viimane ettevalmistav samm hõlmab asukoha määramist, kuhu Visual Studio rakenduse käivitumisel läheb. Valige Visual Studio menüüst Project WebServices Properties, avanevas dialoogiboksis minge vahekaardile Veeb ja märkige jaotises Start Action raadionupp Specific Page. Väärtust pole vaja sisestada – lihtsalt valige raadionupp.

Rakenduse testimiseks selle klassikalisel ASP.NET MVC Frameworki vormil valige Visual Studio silumismenüüst Start Silumine. Näete (veidi veidrat) kõik-ühes paigutust, mis annab kasutajale praeguste broneeringute loendi ning võimaluse neid luua ja kustutada.

Järgmises artiklis lisame oma rakendusele Web API võimalused.

Tere kõigile! Selles artiklis saame aru, mis on SPA veebiarenduses ning millised on selle plussid ja miinused.

Võib-olla on mõni teist juba kuulnud lühendit SPA. Kuid mitte kõik ei pruugi teada, mis see on, nii et uurime välja.

SPA (single page application) on veebirakendus, mis töötab ühel lehel. See laadib lehe esmakordsel laadimisel kõik vajalikud javascripti ja css-failid ning seejärel vähendatakse kogu suhtlus kliendi ja serveri vahel miinimumini. Need. Sellise lähenemise korral tehakse suurem osa saidi tööst ära kliendi poolel ja kui on vaja serverist andmeid hankida, tehakse seda tavaliselt JSONi abil.

See veebisaitide loomise meetod ilmus suhteliselt hiljuti, HTML5 tulekuga, kuid kogub juba aktiivselt hoogu. Põhimõtteliselt pole siin midagi üllatavat, sest selline veebirakendus töötab palju kiiremini kui tavalised saidid ja arendamine ei võta palju aega. Õnneks on nüüd hunnik raamistikke, mis võimaldavad luua seda tüüpi väga keerulisi saite üsna lihtsalt ja kiiresti. Hetkel peetakse Reacti parimaks raamistikuks. Sellel on rohkem eeliseid kui konkurentidel ning seda on ka lihtne õppida ja kasutada. Kui soovite selle kasutamise kohta rohkem teada saada, soovitan pilk peale visata. Nüüd liigume edasi SPA eeliste juurde.

• Toetab suurt hulka seadmeid. Erinevalt tavapärasest lähenemisest töötavad SPA-rakendused ühtviisi hästi nii lauaarvutites kui ka mobiilseadmetes. Nii saate luua ühe rakenduse ja olla kindel, et see ei aeglustu ja töötab ideaalselt ka mitte väga võimsates seadmetes
• Võimas UX. Sellel lähenemisel põhinevates rakendustes on palju lihtsam salvestada erinevat teavet, hallata saidi esitlust ja animatsioone. Samuti, kuna töötav leht on ainult üks, ei ole ilusa kasutajaliidese kirjutamine keeruline
• Suur jõudlus . Tavalistel veebisaitidel on väga sageli näha sama sisu laadimist. Näiteks saidi päis, jalus, menüü ja muud elemendid, mis ei muutu leheküljelt lehele, laaditakse serverist iga kord. SPA lähenemise kasutamisel sellist probleemi lihtsalt ei teki, sest sisu laaditakse vastavalt vajadusele, mis suurendab oluliselt rakenduse kiirust

SPA-l peaaegu puuduvad varjuküljed. Ainus asi, mis väärib märkimist, on see, et selliste rakenduste väljatöötamine peaks toimuma üsna hoolikalt. Asi on selles, et kui esineb näiteks mälulekkeid, võib rakendus hakata tööle palju aeglasemalt, kui me sooviksime. Kuid see kõik sõltub juba arendajast, tema oskustest, seega kui soovite teha kvaliteetseid rakendusi, siis soovitan teil pöörata tähelepanu videokursusele "". Selle koostas professionaal spetsiaalselt selleks, et ka teie saaksite õppida võimsaid ja kiireid rakendusi tegema ning Internetis on kasvanud tõeliselt kvaliteetsete saitide arv.

Niisiis, täna vaatasime, mis on SPA (ühe lehe rakendus), millised on selle eelised ja puudused.

See artikkel keskendub ühelehelisele rakendusele (SPA). Vaadeldakse ühelehelise saidi (SPA) põhimõtetel üles ehitatud veebirakenduse plusse ja miinuseid.

Üheleheline rakendus - lühend SPA, vene keelde tõlgitud tähendab "Ühe lehe rakendus". Ehk SPA on ühel veebilehel majutatud veebirakendus, mis töö tagamiseks laadib koos lehe enda laadimisega ka kogu vajaliku koodi. Seda tüüpi rakendused ilmusid suhteliselt hiljuti, HTML5 ajastu alguses ja SPA on tüüpiline HTML5 rakenduste esindaja.

Nagu me teame, pole HTML5 midagi muud kui HTML + CSS3 + JavaScript + [mõned uued sildid]. Seega on SPA-d JavaScriptis kirjutatud rakendused. Ja seetõttu, pisut parafraseerides eelmist määratlust, saame:

"SPA on ühel lehel hostitud veebirakendus, mis töö tagamiseks laadib kõik javascripti failid (moodulid, vidinad, juhtelemendid jne), aga ka CSS-failid koos lehe enda laadimisega."

Kui rakendus on üsna keeruline ja sisaldab rikkalikke funktsioone, näiteks elektroonilist dokumendihaldussüsteemi, võib skriptidega failide arv ulatuda mitmesaja või isegi tuhandeni. Ja “...loading all scripts...” ei tähenda mingil juhul seda, et saidi laadimisel laetakse korraga alla kõik sajad ja tuhanded skriptidega failid. Suure hulga skriptide SPA-sse laadimise probleemi lahendamiseks kutsutakse välja API nimega AMD. AMD rakendab võimalust nõudmisel skripte alla laadida. See tähendab, et kui ühelehelise portaali “pealeht” nõudis 3 skripti, laaditakse need vahetult enne programmi käivitamist. Ja kui kasutaja klõpsas ühelehelise portaali mõnel teisel lehel, näiteks "Teave programmi kohta", laadib AMD põhimõte mooduli (skript + märgistus) alles enne sellele lehele minekut.

Selgub, et on veidi kortsus: “Üks leht... teine ​​leht, kolmas leht... üheleheküljeline portaal.” Tähistame kõik E-tähed. Veebileheks nimetame saidi lehte, millel kõik lingid kõigile CSS-idele ja lingid skriptidele, mis on vajalikud SPA jaoks, nimetame. Sellise lehega faili nimetatakse tavaliselt "index.html" (ASP.NET MVC-s võib see olla index.cshtml või index.vbhtml või isegi index.aspx) Ja lehti, mida kasutaja ühe lehe sees vahetab portaali nimetatakse mooduliteks.

Vaatame selle lähenemisviisi plusse ja miinuseid. Miks seda kõike vaja on ja miks on SPA nii populaarne?

Esimene eelis, mis väärib märkimist, on asjaolu, et SPA-rakendused töötavad ideaalselt nii laua- kui ka mobiilseadmetes. “Suured” arvutid, tahvelarvutid, nutitelefonid ja lõpuks ka lihtsad telefonid (mõned) saavad hõlpsasti töötada SPA-põhimõttel ehitatud saitidega. Niisiis, esimene "pluss" on see, et see töötab paljudes seadmetes, mis tähendab, et ühe rakenduse loomisega saate palju suurema kasutajaskonna kui tavapärast lähenemist kasutades.

Järgmiseks on teine ​​"pluss" rikkalik kasutajaliides, nn kasutajakogemus. Kuna veebilehti on ainult üks, on rikkaliku ja rikkaliku kasutajaliidese loomine palju lihtsam. Lihtsam on salvestada seansi teavet, hallata vaate olekuid ja juhtida animatsiooni (mõnel juhul).

Kolmas "pluss" on see, et SPA vähendab oluliselt (mitmekordselt) nn "ringitamist" ehk sama sisu ikka ja jälle allalaadimist. Kui teie portaal (sait) kasutab malli, peab saidi külastaja koos mis tahes lehe põhisisuga alla laadima ka malli märgistuse. Jah, andmete vahemällu salvestamine selles WWW arenduse etapis on saavutanud kõige kõrgemaid tulemusi, aga kui pole midagi vahemällu salvestada, siis ei raisata sellele ei aega ega ressursse.

Kui programmeerida C# keeles, siis SPA ainsaks puuduseks on JavaScripti õppimise vajadus. Igatahes ei suutnud ma mingeid muid globaalseid probleeme välja selgitada.

Iga SPA paradigmat rakendava raamistiku (neist räägime hiljem) põhimõtted peavad järgima järgmisi mõisteid ja määratlusi:

• SPA toetab kliendi navigeerimist. Kõik kasutaja “kõnnid” läbi lehemoodulite salvestatakse unikaalselt navigeerimisajalukku ja navigeerimine on “sügav”, st kui kasutaja kopeerib ja avab teises brauseris või aknas lingi sisemise lehe moodulile, siis ta. suunatakse vastavale lehele.
• SPA asub ühel veebilehel, mis tähendab, et kõik saidi (portaali) tööks vajalik, skriptid ja stiilid peavad olema projektis defineeritud ühes kohas – ühel veebilehel.
• SPA salvestab püsivalt kliendi (kliendi skripti) oleku (olulised muutujad) brauseri vahemällu või veebimällu.
• SPA laadib veebilehe initsialiseerimisel kõik rakenduse käivitamiseks vajalikud skriptid.
• SPA laadib mooduleid järk-järgult nõudmisel.

Nagu te ilmselt juba arvasite, on SPA abstraktne mõiste. See on rakenduse arhitektuuri põhimõte. Räägime sellest, millest alustada kodulehe arendamisel SPA põhimõtete järgi.

On olemas suur hulk põhiteeke (raamistik - ingliskeelsest sõnast raamistik - "alus, struktuur, raam"), mis rakendavad ühe lehe rakenduse põhimõtet. Mida need raamistikud pakuvad:

• sätestada SPA arendamise aluspõhimõtted, tööjõukulude minimeerimine universaalsete probleemide lahendamiseks (vt jaotist „SPA komponendid“);
• raamistikud lõi arendajate kogukond, mis tähendab, et nad kasutavad paljude programmeerijate veebisaitide loomise kogemust;
• raamistikud on lähtepunktiks ühelehelisel rakendusel põhineva struktuuri loomisel.

Kuna olen NET-i platvormil töötanud aastaid, siis vaatan ma ASP.NET-il põhinevaid üheleherakenduste malle. Vaatame järgmist võrdlustabelit.

Tabelis on toodud kõige levinumad mallid ühelehelise rakenduse koostamiseks. Pange tähele, et põhilised ehitusplokid täisväärtusliku raamistiku ehitamiseks, nagu DurandalJS ja HotTowel, mis on esile tõstetud rohelisega, on esile tõstetud sinisega.

Pilveveebirakendused koguvad populaarsust. Paljud IT-ettevõtted näevad seda trendi ja üha enam arendatakse kaugjuurdepääsul põhinevaid tarkvaratooteid. Sarnaseid töölauaprogramme, mis pakuvad veebiversiooni väikese kuutasu eest, on palju.

Need pakuvad rohkem paindlikkust ja liikuvust. Näiteks saab oma mobiiltelefoni kaudu hõlpsasti andmeid pilve CRM-i või ERP-süsteemidesse sisestada ja see võib juhtuda teile sobivas kohas. Nagu Statista graafikult näha, pilvelahenduste turg kasvab ja peaks 2026. aastaks ulatuma peaaegu 522 miljardi dollarini.

Keeruliste veebirakenduste stabiilse töö tagamiseks on soovitatav kasutada tehnoloogiaid, mis tagavad parima jõudluse ja kiiruse. Veebirakenduste arendamiseks on kaks võimalust: ühelehelised rakendused (SPA) ja mitmeleheküljelised rakendused (MPA). Vaatame nende erinevust ja milliseid eeliseid igat tüüpi veebirakendustel on.

Ühelehelised rakendused võimaldavad simuleerida töölauarakenduste tööd. Arhitektuur on kujundatud nii, et uuele lehele minnes uuendatakse ainult osa sisust. Nii pole vaja samu üksusi uuesti alla laadida. See on arendajatele ja kasutajatele väga mugav. SPA arendamiseks kasutatakse üht populaarseimat programmeerimiskeelt - javascripti. jQuery teegiga saab teha väikese veebirakenduse.

Kuid tasub kohe märkida, et jQuery sobib suurte projektide arendamiseks väga halvasti. Meie ettevõte Merehead soovitab kasutada SPA arendamiseks võimsamaid tehnoloogiaid. Nendel eesmärkidel sobivad hästi React.js, Angular.js, Vue.js ja muud raamistikud/teegid. Nende arhitektuur võimaldab arendada paindlikke veebirakendusi. Lisaks saate raamistike põhjal luua korduva kasutamisega mobiilirakendusi. Selliseid võimalusi pakuvad Rreact Native ja Ionic. Ühelehelise rakenduse peamised eelised:

Kõigist eelistest hoolimata on ühelehelisel rakendusel mõned puudused, mis takistavad populaarsuse kasvu:

JavaScriptil on madal turvatase, kuid kui kasutate kaasaegseid raamistikke, võivad need teie veebirakenduse turvaliseks muuta. Kuid väärib märkimist, et jQuery kasutamine võib teie projekti turvalisust oluliselt vähendada.

Ühelehelised veebirakendused sobivad hästi väikese andmemahuga dünaamiliste platvormide arendamiseks. Lisaks, kui on vaja tulevikus mobiilirakendust ehitada, sobib SPA suurepäraselt baasiks. Peamine puudus, mis SPA populaarsuse kiiret kasvu pidurdab, on kehv SEO optimeerimine. Projektid, kus SEO on esmatähtis, peaksid kasutama MPA-d.

Mitmeleheküljelised rakendused on klassikalisema arhitektuuriga. Iga leht saadab serverile päringu ja värskendab täielikult kõiki andmeid. Isegi kui need andmed on väikesed. Seega kulub jõudlus samade elementide kuvamisele. Sellest tulenevalt mõjutab see kiirust ja jõudlust. Paljud arendajad kasutavad kiiruse suurendamiseks ja töökoormuse vähendamiseks JavaScripti/jQueryt. Hea näide on veebipoes filtreid kasutades toodete uuendamine ilma lehte uuesti laadimata. See on palju mugavam ja mis kõige tähtsam - kiirem. Mitmeleheküljelise rakenduse (MPA) peamised eelised:

Kasutades MPA-d, leiate sobiva karbilahenduse. Näiteks kasutage e-kaubanduse veebirakenduse arendamiseks Magento, OpenCart või suhtlusvõrgustike arendamiseks Dolphin, Elgg. MPA puudused:

MPA peamine eelis on hea SEO optimeerimine ja tohutu hulk pakendatud lahendusi.