Add Signal.is() as a shortcut for Signal.map()

Flow
1

I am currently using the following code pattern with the new signals api:

public enum State {
    UPLOAD,
    UPLOADING,
    PREVIEW
}

private final ValueSignal<State> stateSignal = new ValueSignal<>(State.UPLOAD);

upload.bindVisible(stateSignal.map(it -> it == State.UPLOAD));
progress.bindVisible(stateSignal.map(it -> it == State.UPLOADING));

I think it would help a lot with readability if there was a function which returns a Signal<Boolean> and internally compares the given value to the signal value.

upload.bindVisible(stateSignal.is(State.UPLOAD));
progress.bindVisible(stateSignal.is(State.UPLOADING));
2

We also have to balance these kinds of shorthands against the risk of bloating the API too much but this is indeed a tempting candidate. One immediate question is whether it would also be relevant to have an isNot shorthand rather than doing Signal.not(someSignal.is(someValue))?

Could also note that a slightly shorter option exists for your case: stateSignal.map(State.UPLOAD::equals).

1 Like
3

I think both shortcuts would come in really handy given how frequent bindings are when using signals. Instead of is and isNot it could also be isAny(a, b, c) and isNone(a, b, c) (using varargs), allowing more use cases with the same amount of methods.

4

I agree with the usefulness of isAny and isNone as well but those suggestions also highlight the danger since we’re suddenly now considering to add four new methods to the API instead of only a single new method. Each method comes with a price since it dilutes the API by making all other methods more difficult to find.

5

isAny replaces is and isNone replaces isNot since they can be used with a single parameter. So it’s just two methods. Or one if you’d use Signal.not().

6

Why not just allow varargs for is instead of having isAny? The single-parameter use case is probably by far the most common.

7

There are some trade-offs there:

  • is(FOO, BAR) isn’t necessarily explicit on whether that’s an AND, OR, or XOR comparison. It’s quite clear in the case of enums that don’t allow overlaps but we might also want to take into account cases where values can overlap.
  • isAny(FOO) looks weird since the method name implies that there would be multiple options but only one is given.

I would spontaneously say that it would be an acceptable trade-off to go for the is(FOO, BAR) shape.

1 Like
8

I agree and I think one value equaling multiple others is rarely the case, really.