Cache af svar med AngularJS

Caching af en applikation hjælper os med at opretholde ydeevnen optimalt, i VinkelJS Det er ikke anderledes, hvis vi har de mest ønskede svar gemt i cachen, vil vores ansøgning sandsynligvis være meget hurtigere, end hvis vi ikke havde dem.
Som standard er denne indstilling ikke aktiv, det skyldes, at svarene oprindeligt ikke skulle være i cachen, men hvis vi for eksempel altid vil konsultere oplysninger, der ikke ændres i løbet af dagen, er det godt, at det ikke har hvad de skal se efter hver anmodning.
Det cache den gemmer ganske enkelt midlertidigt de oplysninger, den modtager fra serveren på klienten, det vil sige første gang, vi konsulterer oplysningerne, hvis vi udtrækker dem fra den eksterne kilde, men følgende gange konsulteres det datalager, som applikationen håndterer.
Som vi nævnte cache er som standard deaktiveret, så vi er nødt til at aktivere det hver gang, vi har brug for et svar, der skal gemmes, til dette kan vi bruge indstillingen cache: sandt I den metode, som vi foretager opkaldet til ressourcen, lad os se i det følgende billede, hvordan en lille kode, der gør dette ser ud:

Vi ser da, at vi først ringer med ham $ http metode til den anden metode i dette tilfælde få (), allerede inde, når vi har angivet URL'en til den eksterne ressource, placerer vi også instruktionen cache: sandt som vi havde nævnt, håndterer vi endelig korrekt det vellykkede svar på anmodningen, hvis der er en.
Selvom dette værktøj er ganske godt for programmets ydeevne, kan det nogle gange for brugerens brugervenlighed ikke være så meget, det skyldes flere ting, men det første er på grund af den måde, hvorpå elementerne opdateres.
Samtidig anmodningerVinkelJS det er smart nok at vide, at hvis der er flere samtidige anmodninger, kun udføre en og derefter tjene med resultatet til de andre, men hvad sker der, hvis det er et indhold, der kan vælges af brugeren, i dette tilfælde i første omgang kunne det se gammelt indhold og opdaterer pludselig til nyt indhold.
Derfor skal vi være forsigtige med den måde, hvorpå vi kan bruge dette cacheværktøj i vores applikation, da hvis vi giver det en forkert brug, kan vi påvirke den måde, vores bruger manipulerer appen på en negativ måde.
Vi forklarer dette, fordi selvom svaret kommer fra cachen, er dets natur stadig asynkron, så det vil opføre sig på samme måde, som hvis dataene blev hentet fra Url.
Med dette afslutter vi denne vejledning, da vi ser, at vi har et ekstra værktøj, der giver os mulighed for at øge programmets ydeevne ved at reducere behovet for at søge efter data fra andre ressourcer, med dette cache -værktøj vi kan opnå en ydelse tættere på nul ventetid ved at interagere med applikationen.