2

When you need to add data into an application from a http request, I heard its good practice to:

  1. dispatch an action, which activates an @Effect.
  2. @Effect fetches data from a http request.
  3. This then fires off another action
  4. Which then finally updates the store.

The rationale behind this is because a http call is a side effect, and thus should be handled by the @ngrx/effects library.

Is this good? I find this problematic because once the first action is dispatched, I have no idea if its successful or a failure. The only way I would know is if my State has an "hasErrorHappened" property or something similar. And I do not believe having such property is a good thing

Or is it better to:

  1. Create a service which does the http call, which gets the data
  2. Update the store after the service with that data
Dolan
  • 1,519
  • 4
  • 16
  • 36
  • 1
    This should be helpful for you https://stackoverflow.com/questions/39552067/what-is-the-purpose-of-ngrx-effects-library/39626187#39626187 I am not expert in ngrx, still learning, i like this approach of creating 3 actions for every scenario, one is disptached and others are fail or success. You are listening the action type of first dispeched and you use switchMap to switch to your success or fail case. – stojevskimilan Dec 19 '17 at 19:22

2 Answers2

0

I think it depends on why you want to know that the effect failed. If you only want to indicate to the user that the request has failed you could either use a timeout in the component that actually dispatched the action or if you want to explicitly show the error to the user, what is not always a good idea, you could actually add a lastError and listen on that while the component is waiting for an response. I don't think that the lastError property is a bad thing in the second case because the store should reflect the state of your application and an error that occurred can be part of this state.

Tobske
  • 518
  • 3
  • 12
-1

Yes, you would do that!

Just add another action for error handling, completing 3 actions.

Example: ADD_TODO ADD_TODO_SUCCESS ADD_TODO_FAILED

Luciano Júnior
  • 345
  • 4
  • 10
  • 1
    Ok, but in that case, what happens if I want to show an error message? `ADD_TODO_FAILED` will update the state right? It adds a property on it `"errorMessage": "My Error here"`. I subscribe to this to show the message. I then click on a new page, then click back to the *same* page... What? The error is still there!! Oh! I need to create a **NEW** action called `REMOVE_TODO_ERROR`, on the `ngOnDestroy()`. This is unacceptable. – Dolan Dec 20 '17 at 10:34
  • This is the right idea. You should be decoupling the fetch/success/fail from any component. You can use a service to implement the logic, but have it write to the store. Components should only be looking at the store and asking 'what is the current state?' –  Apr 10 '18 at 22:07
  • ***create a NEW action called REMOVE_TODO_ERROR, on the ngOnDestroy()*** - this shows a lack of thought. The service will clear the error message if a subsequent fetch succeeds. –  Apr 10 '18 at 22:09