Type-safe initial value skipping?

[JakeWharton]

We've seen and heard struggles with the initial value behavior. Some observables emit it (property-based ones) and others do not (event-based ones).

It would be nice to encapsulate this in the type system for guarantees beyond just Javadoc.

public final class InitialValueObservable<T> extends Observable<T> {
  static <T> InitialValueObservable<T> create(InitialValueOnSubscribe<T> f) {
    return new InitialValueObservable<>(f);
  }

  private InitialValueObservable(InitialValueOnSubscribe<T> f) {
    super(f);
  }

  public Observable<T> skipInitialValue() {
    return skip(1);
  }
}

static abstract InitialValueOnSubscribe<T, V extends View> implements OnSubscribe<T> {
  private final V view;

  protected InitialValueOnSubscribe(V view) {
    this.view = view;
  }

  @Override public final void call(Subscriber<? super T> subscriber) {
    attachListener(view, subscriber);
    subscriber.onNext(initialValue(view));
  }

  protected abstract void attachListener(V view, Subscriber<? super T> subscriber);
  protected abstract T initialValue(V view);
}

Consumers could then rely on the type system for guaranteeing both that the observable would emit an initial value and that they could skip it.

RxTextView.textChanges(textView)
    .skipInitialValue()
    .switchMap(v -> suggestions(v))
    .subscribe(adapter);

[dlew]

I know we talked about this a long time ago. I've had a bit of a change of heart on it. It would be nice to indicate somehow that the Observable is expected to emit an initial value. I wonder how the folks at RxJava think about it...

My only concern is that this wouldn't be enough, since you can still use an InitialValueObservable while being completely ignorant of what it does. Just brainstorming - would it be a terrible idea to force the user to choose before using the Observable?

[JakeWharton]

since you can still use an InitialValueObservable while being completely ignorant of what it does

I think this can be viewed as an advantage, but I understand the sentiment.

would it be a terrible idea to force the user to choose before using the Observable?

I believe my initial proposal was opting in to the initial emission. I don't necessarily think that is the right approach either, but it certainly would be explicit.

[JakeWharton]

I think I'm going to make the above proposed change before 0.3 unless there's any compelling argument towards an opt-in approach.

In a casual glance through our codebase, we opt-out far less than we allow the initial value emission. That's just one example of tens of uses. I'm also not confident that I checked every operator that does have an initial value.

[konmik]

I think that the cleanest and the simplest way is to use naming conventions.

RxTextView.text should emit an initial value and updates to the value.

RxTextView.textChanges should emit only updates without initial values.

RxTextView.setText returns Action1 to chain it into Observable.subscribe. But we in fact don't need such method because we have TextView::setText shortcut from retrolambda.

[JakeWharton]

Those overloads would just be implemented using a mechanism like what was
described above but hidden behind convention instead of being an explicit
API.

On Sat, Oct 17, 2015, 10:48 AM Konstantin Mikheev notifications@github.com
wrote:

I think that the cleanest and the simplest way is to use naming
conventions.

RxTextView.text should emit an initial value and updates to the value.

RxTextView.textChanges should emit only updates without initial values.

RxTextView.setText returns Action1 to chain it into Observable.subscribe.
But we in fact don't need such method because we have TextView::setText
shortcut from retrolambda.

—
Reply to this email directly or view it on GitHub
#153 (comment)
.

[JakeWharton]

Punting on this to 2.0 after spending the night prototyping different approaches.

[Miha-x64]

I just wonder: what do you think about BehaviorSubject as a representation of view property which can be both read from and written to?
UPD: okay, this was stupid. BehaviorSubject has current value, but BehaviorSubject#map returns just an Observable and loses current value.