Resolver or Guard - which is more appropriate for fetching data with ngrx The 2019 Stack Overflow Developer Survey Results Are InHow to attach ngrx/store with an angular router guardAngular2 Exploring Resolved Data in canActivate Guard?wait for state in resolver (ngrx)Angular ngrx/store with canActivate route guardhow to make ngrx-store working with canLoad guardAngular ngrx chart/table data@ngrx/store pre-load guard catch errorNgRx effect not working with Angular ResolverHow to manage Angular resolvers in an ngrx environmentHow to access Resolver Data in ngrx/effects? (v7)

How to deal with fear of taking dependencies

Is there a name of the flying bionic bird?

What do hard-Brexiteers want with respect to the Irish border?

Falsification in Math vs Science

Is "plugging out" electronic devices an American expression?

Why did Howard Stark use all the Vibranium they had on a prototype shield?

Why is it "Tumoren" and not "Tumore"?

What is the best strategy for white in this position?

I see my dog run

What could be the right powersource for 15 seconds lifespan disposable giant chainsaw?

Should I use my personal or workplace e-mail when registering to external websites for work purpose?

Limit the amount of RAM Mathematica may access?

Does duplicating a spell with Wish count as casting that spell?

Why don't Unix/Linux systems traverse through directories until they find the required version of a linked library?

Spanish for "widget"

Does it makes sense to buy a new cycle to learn riding?

Inline version of a function returns different value than non-inline version

Output the Arecibo Message

How to make payment on the internet without leaving a money trail?

What does Linus Torvalds mean when he says that Git "never ever" tracks a file?

Inversion Puzzle

I looked up a future colleague on LinkedIn before I started a job. I told my colleague about it and he seemed surprised. Should I apologize?

CiviEvent: Public link for events of a specific type

Is it possible for the two major parties in the UK to form a coalition with each other instead of a much smaller party?



Resolver or Guard - which is more appropriate for fetching data with ngrx



The 2019 Stack Overflow Developer Survey Results Are InHow to attach ngrx/store with an angular router guardAngular2 Exploring Resolved Data in canActivate Guard?wait for state in resolver (ngrx)Angular ngrx/store with canActivate route guardhow to make ngrx-store working with canLoad guardAngular ngrx chart/table data@ngrx/store pre-load guard catch errorNgRx effect not working with Angular ResolverHow to manage Angular resolvers in an ngrx environmentHow to access Resolver Data in ngrx/effects? (v7)



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








1















Using Angular and ngrx, I want to navigate to a route and ensure that the required data is available in the ngrx/store. I am using a ngrx/store action/effect/reducer to physically call the API. The component that the route is loading accesses the data via the store, as other parts of the system may update the data.



If data fails to load, a LOAD_FAILED action is dispatched, which could be handled in numerous ways.



Should I use a guard or a resolver? What are some other pros and cons of each approach? What have you tried, and if you had your time again, would you do it the same way? Below are some of my thoughts.



Option 1: Guard



When the route is accessed, a guard's canActivate checks to see if the data is in the store, and if not, loads it from the API, and adds it to the store . If data fails to load, canActivate will then return false (as an observable).



This approach has the downside of "loading data shouldn't be a guard's responsibility", but has the upside of preventing access if data cannot be loaded, and the router can handle the fall-through to a "not found", both of which are within the responsibilities.



Option 2: Resolver



When the route is accessed, and any other guards have allowed activation, the resolver is called. This resolver checks if the data is in the store, and if not, fires off a LOAD action, to load from the API and add to the store. Then, once the data has been loaded, the resolver returns some arbitrary data, which is discarded by the route/component, as the component uses the store. If data fails to load, something would redirect to the not found page



This approach has the downside that the resolver is not being used in a traditional sense, e.g. the data that it returns is discarded. Additionally, either the resolver needs to redirect to 404 when not found, or the LOAD_FAILED needs to redirect. This adds complexity, as there may be times when LOAD_FAILED shouldn't redirect, e.g. when a background action triggers a load. On the upside, it is the responsibility of a resolver to load data.










share|improve this question
























  • I personally would use guards and resolvers for exactly what they are. However, since you are using ngrx and don't have to worry about getting pre-fetched data from resolvers, I think you'd be okay either way.

    – Anjil Dhamala
    Mar 22 at 3:02











  • @AnjilDhamala, thanks for your comment. The question here is actually about which is more appropriate- a guard is meant to allow/prevent access, but in this case, "no having the data" is what we want to guard against. Resolvers are meant to fetch data, so that seems logical. If resolvers executed before guards, it would make sense to use both, but since guards execute first, I am not entirely clear as to the best approach!

    – AndrewP
    Mar 22 at 4:58

















1















Using Angular and ngrx, I want to navigate to a route and ensure that the required data is available in the ngrx/store. I am using a ngrx/store action/effect/reducer to physically call the API. The component that the route is loading accesses the data via the store, as other parts of the system may update the data.



If data fails to load, a LOAD_FAILED action is dispatched, which could be handled in numerous ways.



Should I use a guard or a resolver? What are some other pros and cons of each approach? What have you tried, and if you had your time again, would you do it the same way? Below are some of my thoughts.



Option 1: Guard



When the route is accessed, a guard's canActivate checks to see if the data is in the store, and if not, loads it from the API, and adds it to the store . If data fails to load, canActivate will then return false (as an observable).



This approach has the downside of "loading data shouldn't be a guard's responsibility", but has the upside of preventing access if data cannot be loaded, and the router can handle the fall-through to a "not found", both of which are within the responsibilities.



Option 2: Resolver



When the route is accessed, and any other guards have allowed activation, the resolver is called. This resolver checks if the data is in the store, and if not, fires off a LOAD action, to load from the API and add to the store. Then, once the data has been loaded, the resolver returns some arbitrary data, which is discarded by the route/component, as the component uses the store. If data fails to load, something would redirect to the not found page



This approach has the downside that the resolver is not being used in a traditional sense, e.g. the data that it returns is discarded. Additionally, either the resolver needs to redirect to 404 when not found, or the LOAD_FAILED needs to redirect. This adds complexity, as there may be times when LOAD_FAILED shouldn't redirect, e.g. when a background action triggers a load. On the upside, it is the responsibility of a resolver to load data.










share|improve this question
























  • I personally would use guards and resolvers for exactly what they are. However, since you are using ngrx and don't have to worry about getting pre-fetched data from resolvers, I think you'd be okay either way.

    – Anjil Dhamala
    Mar 22 at 3:02











  • @AnjilDhamala, thanks for your comment. The question here is actually about which is more appropriate- a guard is meant to allow/prevent access, but in this case, "no having the data" is what we want to guard against. Resolvers are meant to fetch data, so that seems logical. If resolvers executed before guards, it would make sense to use both, but since guards execute first, I am not entirely clear as to the best approach!

    – AndrewP
    Mar 22 at 4:58













1












1








1








Using Angular and ngrx, I want to navigate to a route and ensure that the required data is available in the ngrx/store. I am using a ngrx/store action/effect/reducer to physically call the API. The component that the route is loading accesses the data via the store, as other parts of the system may update the data.



If data fails to load, a LOAD_FAILED action is dispatched, which could be handled in numerous ways.



Should I use a guard or a resolver? What are some other pros and cons of each approach? What have you tried, and if you had your time again, would you do it the same way? Below are some of my thoughts.



Option 1: Guard



When the route is accessed, a guard's canActivate checks to see if the data is in the store, and if not, loads it from the API, and adds it to the store . If data fails to load, canActivate will then return false (as an observable).



This approach has the downside of "loading data shouldn't be a guard's responsibility", but has the upside of preventing access if data cannot be loaded, and the router can handle the fall-through to a "not found", both of which are within the responsibilities.



Option 2: Resolver



When the route is accessed, and any other guards have allowed activation, the resolver is called. This resolver checks if the data is in the store, and if not, fires off a LOAD action, to load from the API and add to the store. Then, once the data has been loaded, the resolver returns some arbitrary data, which is discarded by the route/component, as the component uses the store. If data fails to load, something would redirect to the not found page



This approach has the downside that the resolver is not being used in a traditional sense, e.g. the data that it returns is discarded. Additionally, either the resolver needs to redirect to 404 when not found, or the LOAD_FAILED needs to redirect. This adds complexity, as there may be times when LOAD_FAILED shouldn't redirect, e.g. when a background action triggers a load. On the upside, it is the responsibility of a resolver to load data.










share|improve this question
















Using Angular and ngrx, I want to navigate to a route and ensure that the required data is available in the ngrx/store. I am using a ngrx/store action/effect/reducer to physically call the API. The component that the route is loading accesses the data via the store, as other parts of the system may update the data.



If data fails to load, a LOAD_FAILED action is dispatched, which could be handled in numerous ways.



Should I use a guard or a resolver? What are some other pros and cons of each approach? What have you tried, and if you had your time again, would you do it the same way? Below are some of my thoughts.



Option 1: Guard



When the route is accessed, a guard's canActivate checks to see if the data is in the store, and if not, loads it from the API, and adds it to the store . If data fails to load, canActivate will then return false (as an observable).



This approach has the downside of "loading data shouldn't be a guard's responsibility", but has the upside of preventing access if data cannot be loaded, and the router can handle the fall-through to a "not found", both of which are within the responsibilities.



Option 2: Resolver



When the route is accessed, and any other guards have allowed activation, the resolver is called. This resolver checks if the data is in the store, and if not, fires off a LOAD action, to load from the API and add to the store. Then, once the data has been loaded, the resolver returns some arbitrary data, which is discarded by the route/component, as the component uses the store. If data fails to load, something would redirect to the not found page



This approach has the downside that the resolver is not being used in a traditional sense, e.g. the data that it returns is discarded. Additionally, either the resolver needs to redirect to 404 when not found, or the LOAD_FAILED needs to redirect. This adds complexity, as there may be times when LOAD_FAILED shouldn't redirect, e.g. when a background action triggers a load. On the upside, it is the responsibility of a resolver to load data.







angular ngrx ngrx-store






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 22 at 4:57







AndrewP

















asked Mar 22 at 2:50









AndrewPAndrewP

1,066616




1,066616












  • I personally would use guards and resolvers for exactly what they are. However, since you are using ngrx and don't have to worry about getting pre-fetched data from resolvers, I think you'd be okay either way.

    – Anjil Dhamala
    Mar 22 at 3:02











  • @AnjilDhamala, thanks for your comment. The question here is actually about which is more appropriate- a guard is meant to allow/prevent access, but in this case, "no having the data" is what we want to guard against. Resolvers are meant to fetch data, so that seems logical. If resolvers executed before guards, it would make sense to use both, but since guards execute first, I am not entirely clear as to the best approach!

    – AndrewP
    Mar 22 at 4:58

















  • I personally would use guards and resolvers for exactly what they are. However, since you are using ngrx and don't have to worry about getting pre-fetched data from resolvers, I think you'd be okay either way.

    – Anjil Dhamala
    Mar 22 at 3:02











  • @AnjilDhamala, thanks for your comment. The question here is actually about which is more appropriate- a guard is meant to allow/prevent access, but in this case, "no having the data" is what we want to guard against. Resolvers are meant to fetch data, so that seems logical. If resolvers executed before guards, it would make sense to use both, but since guards execute first, I am not entirely clear as to the best approach!

    – AndrewP
    Mar 22 at 4:58
















I personally would use guards and resolvers for exactly what they are. However, since you are using ngrx and don't have to worry about getting pre-fetched data from resolvers, I think you'd be okay either way.

– Anjil Dhamala
Mar 22 at 3:02





I personally would use guards and resolvers for exactly what they are. However, since you are using ngrx and don't have to worry about getting pre-fetched data from resolvers, I think you'd be okay either way.

– Anjil Dhamala
Mar 22 at 3:02













@AnjilDhamala, thanks for your comment. The question here is actually about which is more appropriate- a guard is meant to allow/prevent access, but in this case, "no having the data" is what we want to guard against. Resolvers are meant to fetch data, so that seems logical. If resolvers executed before guards, it would make sense to use both, but since guards execute first, I am not entirely clear as to the best approach!

– AndrewP
Mar 22 at 4:58





@AnjilDhamala, thanks for your comment. The question here is actually about which is more appropriate- a guard is meant to allow/prevent access, but in this case, "no having the data" is what we want to guard against. Resolvers are meant to fetch data, so that seems logical. If resolvers executed before guards, it would make sense to use both, but since guards execute first, I am not entirely clear as to the best approach!

– AndrewP
Mar 22 at 4:58












0






active

oldest

votes












Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55292199%2fresolver-or-guard-which-is-more-appropriate-for-fetching-data-with-ngrx%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55292199%2fresolver-or-guard-which-is-more-appropriate-for-fetching-data-with-ngrx%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현