- Turning an eager, pure computation into a lazy one:
- Side-effecting work that is safe to perform multiple times:
- Side-effecting work that is safe to perform multiple times serially, but not concurrently:
RACSchedulerwould seem to apply here, but execution could become interleaved and thus not serial
- Side-effecting work that should only be performed once, then memoized:
- Enabling/disabling a UI based on whether work can be performed:
- Replaying is a Good Idea™ because this information may arrive before the UI is ready for it
- Updating a UI with information about work in progress:
- Requesting work, then receiving a response with values:
RACCommand, creating a
RACSignaland capturing arguments,
- Two-way bindings:
- When validation is used, this sorta ends up looking like bidirectional request-response
- Receiving values from an event source that's always alive (e.g., mouse position):
- For each of the above, what does cancellation mean, if anything?
- Are there any use cases that we should avoid solving? Maybe some of them belong somewhere other than RAC.
- How do we design an API that provides exactly one solution for each use case? For complex problems that meet more than one of the use cases above, our solutions should be small, purpose-specific, and composable, instead of trying to solve all the things at once.
- Focus on cold signals.
- Apply backpressure from consumers to producers.
RACMulticastConnection(possibly renamed) front and center as a way to perform memoized side effects. Remove or seriously de-emphasize subjects, and remove operators like
-replayin favor of using connections explicitly.
RACCommandwith simpler and more composable Kleisli arrows.
- "Enabledness" operator: returns a signal of enabledness, and the original signal, except the latter will error upon subscription if disabled (a la