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)
What to do when moving next to a bird sanctuary with a loosely-domesticated cat?
Identify boardgame from Big movie
Can one be advised by a professor who is very far away?
FPGA - DIY Programming
What is the accessibility of a package's `Private` context variables?
Why do UK politicians seemingly ignore opinion polls on Brexit?
Have you ever entered Singapore using a different passport or name?
What is the meaning of the verb "bear" in this context?
Did 3000BC Egyptians use meteoric iron weapons?
Can someone be penalized for an "unlawful" act if no penalty is specified?
What tool would a Roman-age civilization have for the breaking of silver and other metals into dust?
Worn-tile Scrabble
Can we generate random numbers using irrational numbers like π and e?
Are spiders unable to hurt humans, especially very small spiders?
How to save as into a customized destination on macOS?
What do the Banks children have against barley water?
Did Scotland spend $250,000 for the slogan "Welcome to Scotland"?
Can you compress metal and what would be the consequences?
Feature engineering suggestion required
What could be the right powersource for 15 seconds lifespan disposable giant chainsaw?
What is the meaning of Triage in Cybersec world?
Is bread bad for ducks?
Why is the maximum length of OpenWrt’s root password 8 characters?
Is this app Icon Browser Safe/Legit?
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;
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 asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
add a comment |
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 asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
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
add a comment |
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 asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
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 angular ngrx ngrx-store asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
edited Mar 22 at 4:57
AndrewP
asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
asked Mar 22 at 2:50
AndrewPAndrewP
1,068616
1,068616
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
In my project we are using NgRx store, and we are using Guards to fetch data. There are pros and cons of this approach, but from my point of view Resolvers are not well suited for this type of data processing, and Angular is missing some additional class, such as PreloadingGuard (or sth similar) - something what would sit between guard and resolver - would be responsible for fetching data, but won't access the route. Lets list out what the cons and pros are:
Cons:
- fetching data is not Guard responsibility, it's against their definition
Pros:
The data has to be persisted inside the store before the redirect is actually done - this is 'must'. One would say that we could use *ngIf on the top of component, but it just looks odd from end user perspective: You are on page A, click the button, then page is white (plus maybe some spinner on top), suddenly the content appears and you're on page B. With guard we don't have 'the white page' part - everything is smooth and nice.
If guard is used and it failed to fetch data - the user is not redirected to another route, he/she stays in previous place. Do same with resolver - and user hangs somewhere in the middle, cause he was already moved him to different route & we need some additional code to move him back to the place where he just have been.
Normally you would you Effect to fetch data asynchronously. You would write actions such as LoadSth, LoadSthSuccess, LoadSthError. With guard you don't need any Effect, and you don't need the 3 actions (LoadSthSuccess is sufficient). You can call your service in guard and then dispatch LoadSthSuccess action. Personally I'm using Effect only when I have to - these beasts are tricky, and I strongly suggest to avoid using them as often as possible. Guards are just better substitutes.
Error handling is much better with Guards. You basically do not want the user to see the broken page (with incomplete data). Guards will help you achieve it - display some error modal and return Observable.of(false) from the guard + stay on previous view
You may use same guard in several places and fetch data ONLY when the state is empty - so you are sure that you are loading the data only once, and you are sure it was actually loaded when you access certain route
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
In my project we are using NgRx store, and we are using Guards to fetch data. There are pros and cons of this approach, but from my point of view Resolvers are not well suited for this type of data processing, and Angular is missing some additional class, such as PreloadingGuard (or sth similar) - something what would sit between guard and resolver - would be responsible for fetching data, but won't access the route. Lets list out what the cons and pros are:
Cons:
- fetching data is not Guard responsibility, it's against their definition
Pros:
The data has to be persisted inside the store before the redirect is actually done - this is 'must'. One would say that we could use *ngIf on the top of component, but it just looks odd from end user perspective: You are on page A, click the button, then page is white (plus maybe some spinner on top), suddenly the content appears and you're on page B. With guard we don't have 'the white page' part - everything is smooth and nice.
If guard is used and it failed to fetch data - the user is not redirected to another route, he/she stays in previous place. Do same with resolver - and user hangs somewhere in the middle, cause he was already moved him to different route & we need some additional code to move him back to the place where he just have been.
Normally you would you Effect to fetch data asynchronously. You would write actions such as LoadSth, LoadSthSuccess, LoadSthError. With guard you don't need any Effect, and you don't need the 3 actions (LoadSthSuccess is sufficient). You can call your service in guard and then dispatch LoadSthSuccess action. Personally I'm using Effect only when I have to - these beasts are tricky, and I strongly suggest to avoid using them as often as possible. Guards are just better substitutes.
Error handling is much better with Guards. You basically do not want the user to see the broken page (with incomplete data). Guards will help you achieve it - display some error modal and return Observable.of(false) from the guard + stay on previous view
You may use same guard in several places and fetch data ONLY when the state is empty - so you are sure that you are loading the data only once, and you are sure it was actually loaded when you access certain route
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
add a comment |
In my project we are using NgRx store, and we are using Guards to fetch data. There are pros and cons of this approach, but from my point of view Resolvers are not well suited for this type of data processing, and Angular is missing some additional class, such as PreloadingGuard (or sth similar) - something what would sit between guard and resolver - would be responsible for fetching data, but won't access the route. Lets list out what the cons and pros are:
Cons:
- fetching data is not Guard responsibility, it's against their definition
Pros:
The data has to be persisted inside the store before the redirect is actually done - this is 'must'. One would say that we could use *ngIf on the top of component, but it just looks odd from end user perspective: You are on page A, click the button, then page is white (plus maybe some spinner on top), suddenly the content appears and you're on page B. With guard we don't have 'the white page' part - everything is smooth and nice.
If guard is used and it failed to fetch data - the user is not redirected to another route, he/she stays in previous place. Do same with resolver - and user hangs somewhere in the middle, cause he was already moved him to different route & we need some additional code to move him back to the place where he just have been.
Normally you would you Effect to fetch data asynchronously. You would write actions such as LoadSth, LoadSthSuccess, LoadSthError. With guard you don't need any Effect, and you don't need the 3 actions (LoadSthSuccess is sufficient). You can call your service in guard and then dispatch LoadSthSuccess action. Personally I'm using Effect only when I have to - these beasts are tricky, and I strongly suggest to avoid using them as often as possible. Guards are just better substitutes.
Error handling is much better with Guards. You basically do not want the user to see the broken page (with incomplete data). Guards will help you achieve it - display some error modal and return Observable.of(false) from the guard + stay on previous view
You may use same guard in several places and fetch data ONLY when the state is empty - so you are sure that you are loading the data only once, and you are sure it was actually loaded when you access certain route
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
add a comment |
In my project we are using NgRx store, and we are using Guards to fetch data. There are pros and cons of this approach, but from my point of view Resolvers are not well suited for this type of data processing, and Angular is missing some additional class, such as PreloadingGuard (or sth similar) - something what would sit between guard and resolver - would be responsible for fetching data, but won't access the route. Lets list out what the cons and pros are:
Cons:
- fetching data is not Guard responsibility, it's against their definition
Pros:
The data has to be persisted inside the store before the redirect is actually done - this is 'must'. One would say that we could use *ngIf on the top of component, but it just looks odd from end user perspective: You are on page A, click the button, then page is white (plus maybe some spinner on top), suddenly the content appears and you're on page B. With guard we don't have 'the white page' part - everything is smooth and nice.
If guard is used and it failed to fetch data - the user is not redirected to another route, he/she stays in previous place. Do same with resolver - and user hangs somewhere in the middle, cause he was already moved him to different route & we need some additional code to move him back to the place where he just have been.
Normally you would you Effect to fetch data asynchronously. You would write actions such as LoadSth, LoadSthSuccess, LoadSthError. With guard you don't need any Effect, and you don't need the 3 actions (LoadSthSuccess is sufficient). You can call your service in guard and then dispatch LoadSthSuccess action. Personally I'm using Effect only when I have to - these beasts are tricky, and I strongly suggest to avoid using them as often as possible. Guards are just better substitutes.
Error handling is much better with Guards. You basically do not want the user to see the broken page (with incomplete data). Guards will help you achieve it - display some error modal and return Observable.of(false) from the guard + stay on previous view
You may use same guard in several places and fetch data ONLY when the state is empty - so you are sure that you are loading the data only once, and you are sure it was actually loaded when you access certain route
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
In my project we are using NgRx store, and we are using Guards to fetch data. There are pros and cons of this approach, but from my point of view Resolvers are not well suited for this type of data processing, and Angular is missing some additional class, such as PreloadingGuard (or sth similar) - something what would sit between guard and resolver - would be responsible for fetching data, but won't access the route. Lets list out what the cons and pros are:
Cons:
- fetching data is not Guard responsibility, it's against their definition
Pros:
The data has to be persisted inside the store before the redirect is actually done - this is 'must'. One would say that we could use *ngIf on the top of component, but it just looks odd from end user perspective: You are on page A, click the button, then page is white (plus maybe some spinner on top), suddenly the content appears and you're on page B. With guard we don't have 'the white page' part - everything is smooth and nice.
If guard is used and it failed to fetch data - the user is not redirected to another route, he/she stays in previous place. Do same with resolver - and user hangs somewhere in the middle, cause he was already moved him to different route & we need some additional code to move him back to the place where he just have been.
Normally you would you Effect to fetch data asynchronously. You would write actions such as LoadSth, LoadSthSuccess, LoadSthError. With guard you don't need any Effect, and you don't need the 3 actions (LoadSthSuccess is sufficient). You can call your service in guard and then dispatch LoadSthSuccess action. Personally I'm using Effect only when I have to - these beasts are tricky, and I strongly suggest to avoid using them as often as possible. Guards are just better substitutes.
Error handling is much better with Guards. You basically do not want the user to see the broken page (with incomplete data). Guards will help you achieve it - display some error modal and return Observable.of(false) from the guard + stay on previous view
You may use same guard in several places and fetch data ONLY when the state is empty - so you are sure that you are loading the data only once, and you are sure it was actually loaded when you access certain route
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
answered 10 hours ago
Pawel KiszkaPawel Kiszka
9111
9111
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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