After an unsubscribe on result$ mutation, mutation is no longer working

[ExFlo]

Which @ngneat/query-* package(s) are the source of the bug?

query

Is this a regression?

No

Description

Hi
To reproduce create a mutation using the service, subscribe to the result$, unsubscribe to it, resubscribe --> all I receive is only a loading result.
My use case is I want to be able to create the mutation in a service and use it in multiple component as I want but after the first unsubscribe I am no longer able to use the mutation.
BR
Florent

Please provide a link to a minimal reproduction of the bug

#81

Please provide the exception or error you saw

After a unsubscribe to a result$ mutation the mutation is not longer working and stay in a loading state (as if the observable is no longer subscribe) even if a valid subscription is still on.

Please provide the environment you discovered this bug in

No response

Anything else?

No response

Do you want to create a pull request?

Yes

[ExFlo]

hi @NetanelBasal I created a codesandbox to reproduce.
here
the mutation add todo (and the button) is working until you unsubscribe once to the results$ after it is no longer working.
BR
Florent

[luii]

@ExFlo Did you already solve this issue? If so, how did you do it?

[ExFlo]

@luii Hi my current workaround is to create the mutation everytime, everywhere I need it. Instead of sharing it in service, I create it in every component I need it...

[luii]

Just so that i better understand the problem, why is it necessary to share the mutation (or the result$ observable)? Could you give me an example where this would make sense - doesnt need to be code though.

What first comes to mind is multicasting (turning cold observables into hot ones) the result$ observable so that as long as you want the result$ is subscribed to and getting updates which are pushed into an replay subject from which participants could (un)subscribe.

  ...

  addTodoOriginal() {
    return this.useMutation(({ title }: { title: string }) => {
      return this.http
        .post<Todo>(`https://jsonplaceholder.typicode.com/todos`, { title })
        .pipe(
          tap(() => {
            this.queryClient.invalidateQueries(["todos"]);
          })
        );
    });
  }

  constructor() {
    this.todos$ = this.getTodos().result$;
    this.addTodoMutation = this.addTodoOriginal();
    this.result$ = this.addTodoMutation.result$.pipe(shareReplay(1));
  }

  add() {
    this.addTodoMutation.mutate({ title: "foo" }).then((res) => {
      console.log(res);
    });
  }

  unsub() {
    this.result$.subscribe().unsubscribe();
  }

  ...

by adding shareReplay you add a ReplaySubject with a buffer count of 1 in between that "so to say" caches the latest value that got pushed into result$, this would persist indefintely. If you'd turn on refCount it would count the Subscribers and if the last Subscriber unsubscribe, then unsubscribe itself from result$ - but this doesnt sound like the behaviour you thought of.

Why use shareReplay?
You generally want to use shareReplay when you have side-effects or taxing computations that you do not wish to be executed amongst multiple subscribers. It may also be valuable in situations where you know you will have late subscribers to a stream that need access to previously emitted values. This ability to replay values on subscription is what differentiates share and shareReplay.

[ExFlo]

Hi @luii Idea is here not to share the current and last result of a mutation but share the code that created the logic of the mutation by reusing the "addTodoMutation" . Imagine I have two components that want to have the "addTodo" button.
I can push the following code in a service

...
constructor() {
    this.addTodoMutation = this.addTodoOriginal();
  }
 addTodoOriginal() {
    return this.useMutation(({ title }: { title: string }) => {
      return this.http
        .post<Todo>(`https://jsonplaceholder.typicode.com/todos`, { title })
        .pipe(
          tap(() => {
            this.queryClient.invalidateQueries(["todos"]);
          })
        );
    });
  }

Inject this service in the two components and use the mutate function on addTodoMutation in both of the components.
I want to avoid creating this addTodoMutation in all the component I want to call the mutate.
BR

[luii]

@ExFlo There is nothing that would prevent you from reusing the mutation, i think. You can still construct the Mutation in the Service and expose the result$ observable with a shareReplay(1) to receive the updates for the two ("example") components you have.
The shareReplay just prevents you from getting stuck in the "loading" loop you described.

I dont think that the behavior you initially described in your Issue is a bug at all, since the lifetime of a mutation most of the time is only as long as a component lives. Using a Service would extend the lifetime of said Mutation to the application lifetime (when providedIn: 'root' is set) or to the lifetime of the Module/Component that provided the Service.

This on the other hand would mean that you're bound to have late Subscribers from time to time (for example having one of the buttons in your app-bar and one on a routed page). This is why you would share and replay the result$ observable to only counter late subscribers from unsubscribing, therefore closing the result$ observable. Nothing more nothing less.

@NetanelBasal What do you think about this? I think it works as intended and should be kept like this.

[luii]

@NetanelBasal Then i would say that we close this Issue since it's working as intended

[NetanelBasal]

Yes. TBH I don't see any advantage of using useMutation, and I'm not using it either.

[NetanelBasal]

See https://github.com/ngneat/query#mutation-result