K
K
ksardi2017-06-22 22:15:43
Angular
ksardi, 2017-06-22 22:15:43

How to return value to component after store.dispatch() (ngrx angular2)?

There is a component of likes, as in the social. networks that accepts data via @Input(), there are more than a hundred such components, so keeping all the data in the store is not an option. The component has a click trigger to add and remove the likes of the current user.
I tried
this.store.dispatch(addAction)
and update the data for the ui based on the result (you need to get the id from the server from the effect result),
but how to get the data from the action result in the component?
here is the
effect of public likeChangeAdd: Observable = this.actions
.ofType(ActionTypes.LIKE_CHANGE_ADD)
.map(toPayload)
.switchMap(payload => {
return this.authHttp.post(`${environment.backUrl}/api/likes`, payload )
.map((res) => {
return new LikesChangeSuccessAction({result: res.json()});
})
.catch((error) => {
return Observable.of(new LikesChangeErrorAction({error: error}));
})
});
here is the data component
in the form // this.data = [{id:1, user_id:2},{...}]
public trigger(): void {
if (!this.isLiked()) {
this.store.dispatch (LikeAddAction({topic: this.id, user: this.userId}));
// in the response from the server, the id to be inserted into the data
array this.data.push({id: res.id, user_id: this.userId}); // here I need to pull out the response
});
} else // dispatch for remove
};

Answer the question

In order to leave comments, you need to log in

1 answer(s)
A
Aleksei Podgaev, 2017-06-25
@alexiusp

Well, firstly, why, in fact, storing everything in the store is not an option? Somewhere it still has to be stored. I would store in store.
But if you still want something more complicated, then you can make your own Subject for this event (from rx.js). Those components that need to know about this event subscribe to this Subject, and the service that receives the data calls Subject.next with data about the like. The difference between a Subject and an Observable is that a Subject can have any number of subscribers, and all of them will know about the event. Sounds like this is what you need? The only thing that confuses me here is whether such a solution would be even more resource-intensive than storing all the data in the store.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question