Retrofit: Feature request: @Passthru variable for Rx chains

Created on 20 May 2015  路  3Comments  路  Source: square/retrofit

One of the key advantages of Reactive Programming is to eliminate mutable state and potential race conditions by passing variables down the observable chain. This ensures that the result of a first network request is safely stored in the Observable chain to be used by a later operation in the chain and cannot be overwritten by an unrelated operation.

I would like to propose a @Passthru annotation for introducing variables to Retrofit operations, requiring a java.util.Pair return value. Using this variable annotation and Pair value, later operations could access stored knowledge about past operations in the chain or about saved state from any point in the chain.

It's possible that there may be other implementations that make sense by passing old variables into the response POJO, but the response POJO would no longer accurately model the network response.

Most helpful comment

This is a problem with all observables, not Retrofit. The workaround is to use flatMap to have access to the outer state and the result of the new observable:

interface BarService {
  @GET("/bar")
  Observable<Bar> bar();
}

foos.flatMap(foo -> {
  return barService.bar()
    .map(bar -> {
      return FooBar(foo, bar);
    });
}).subscribe(fooBar -> {
  System.out.println("GOT: " + fooBar);
});

There is some investigation being done for a first-party solution to this problem. See https://github.com/ReactiveX/RxJava/issues/2885 and https://github.com/ReactiveX/RxJava/issues/2931

All 3 comments

This is a problem with all observables, not Retrofit. The workaround is to use flatMap to have access to the outer state and the result of the new observable:

interface BarService {
  @GET("/bar")
  Observable<Bar> bar();
}

foos.flatMap(foo -> {
  return barService.bar()
    .map(bar -> {
      return FooBar(foo, bar);
    });
}).subscribe(fooBar -> {
  System.out.println("GOT: " + fooBar);
});

There is some investigation being done for a first-party solution to this problem. See https://github.com/ReactiveX/RxJava/issues/2885 and https://github.com/ReactiveX/RxJava/issues/2931

Thanks so much for the quick response. I was wondering what people were doing about this issue for now. It seemed too common a need to be unsolved.

I agree that it can be quite annoying :+1:

Was this page helpful?
0 / 5 - 0 ratings