Кеш одговора са АнгуларЈС -ом

Кеширање апликације помаже нам да оптимално одржимо перформансе, у АнгуларЈС Није ништа другачије, ако имамо најтраженије одговоре ускладиштене у кешу, наша апликација ће вероватно бити много бржа него да их немамо.
Ова опција подразумевано није активна, то је зато што првобитно одговори не би требало да буду у кешу, али на пример ако ћемо увек консултовати информације које се неће променити током дана, добро је да нема шта да ради потражите сваку захтев.
Тхе кеш једноставно привремено складишти информације које прима од сервера на клијенту, то јест, први пут када консултујемо информације ако их издвојимо из спољног извора, али следећи пут се консултује спремиште података којим апликација рукује.
Као што смо поменули кеш је подразумевано онемогућен, тако да га морамо активирати сваки пут кад нам је потребан одговор за спремање, за то можемо користити опцију кеш: труе У методи помоћу које позивамо ресурс, да видимо на следећој слици како изгледа мали код који ово ради:

Видимо да тада прво зовемо с њим $ хттп метод на другу методу у овом случају добити (), већ унутра након што наведемо УРЛ спољног извора, такође постављамо упутство кеш: труе које смо споменули, коначно смо правилно решили успешан одговор на захтев ако постоји.
Иако је овај услужни програм прилично добар за перформансе апликације, понекад због лакше употребе корисника не може бити толико, то је због неколико ствари, али прва је због начина на који се елементи освјежавају.
Истовремени захтевиАнгуларЈС довољно је паметно знати да ако постоји неколико истовремених захтева, само један изврши, а затим послужи са резултатом осталима, али шта се дешава ако се ради о садржају који бира корисник, у овом случају би у првом случају могао да види стари садржај и одједном ажурирање на нови садржај.
Зато морамо бити опрезни на начин на који можемо користити овај алат за кеширање у нашој апликацији, јер ако му дамо нетачну употребу, можемо утицати на начин на који наш корисник манипулише апликацијом на негативан начин.
Ово објашњавамо јер, иако одговор долази из предмеморије, његова природа је и даље асинхрона, па ће се понашати на исти начин као да су подаци добијени из Урл.
Овим завршавамо овај водич, јер видимо да имамо додатни алат који нам омогућава да повећамо перформансе апликације смањењем потребе за тражењем података из других ресурса, са овим алатка за кеширање интеракцијом са апликацијом можемо постићи перформансе ближе нули чекања.