Goal: build a javascript bridge that can commit streams to a native MotionRuntime.

The bridge would ideally only be executed one time for a given director. E.g. a given transition might have a javascript bridge that can be used to drive the transition.

The javascript director will have a single mechanism for adding streams to a runtime, e.g. transition.runtime.write(to:)

Spec: https://material-motion.github.io/material-motion/starmap/specifications/streams/operators/$._filter

We may want to treat Int values as CGFloat types throughout material motion in order to ease use of simple constants, e.g. 0 or 1 without requiring need for explicit typing, e.g. CGFloat(0) or CGFloat(1).

We currently use a hacky Hidden interaction that hides the view and unhides it when the runtime is deallocated (i.e. the transition has completed).

https://material-motion.github.io/material-motion/starmap/specifications/streams/operators/$.write

Doing so allows the instance to change after the stream has been subscribed, leading to potentially unexpected behavior. We want to provide a guarantee that once a spring/tween has been subscribed to, subsequent changes to the spring/tween won't affect that stream.

let spring = Spring(to: 1, threshold: 0.1, system: coreAnimation)

Ambiguous reference to member 'coreAnimation(_:initialValue:)'

Solution is to cast:

let spring = Spring(to: CGFloat(1), threshold: 0.1, system: coreAnimation)

But we should support using literal numbers as well.

Unclear what this API would look like, but ideally there'd be some way to turn:

let someStream = gesture.translation().xLocked(to: 20)

into

gesture => { ... } => translation() => {50, 20} => xLocked(to: 50) => {20, 20}

or something similar. This would be emitted in real time to the console.

Some possible approaches:

• Create an operator that traces anything upstream of it. E.g. gesture.translation().xLocked(to: 20).trace()

It's currently an operator and requires use of runtime.connect. Ideally it would be an interaction with the relevant configurable properties, e.g. slop size.

Challenge here is building an interaction that supports n-dimensional slopping, e.g. vertical/horizontal slop or slop outside of a 2d region.

This is due to the anchor point being adjusted. The draggable interaction needs to know that the anchor point has changed in order for it not to jump. This may require some coordination between anchor point adjustments and the draggable operators.

This is because each of these is a distinct property instance. This can be confusing to the end user. The "hack" fix is to always use the same property and apply constraints on it instead, e.g. position.x() and position.y().

Ideally the positionX and positionY properties would react to changes to position.

Note that changes to positionX and positionY do propagate to position because they use externalWrite to adjust the position property.

Resolving this would probably be a matter of having property do an external write to positionX and positionY, so long as this didn't cause a retain cycle.

Context: sticker picker case study.

The current case study registers directly manipulable to each sticker view directly. This ensures that each sticker view is individually manipulable, but doesn't allow you to pinch outside of a sticker in order to affect it.

Ideally it would be possible to register a single gesture recognizer set to the parent view and to only have them modify the top-most view at the centroid of the gestural interaction. This logic could be built into DirectlyManipulable as a feature with the following characteristics:

1. Only one set of gesture recognizers is added to the parent view.
2. The gesture recognizer delegate allows simultaneous recognition, as before.
3. The gesture recognizer only begins if one of the target views is within the centroid of the gesture.
4. Only the top-most target view is affected by the gesture.

We don't need to generate a globally-unique id: a simple counter will suffice.

runtime.get is currently making use of function overloading to create and cache reactive versions of non-reactive objects. This will create problems when working with sub-types, such as CAShapeLayer, because now the sub-type has its own cache. Consider the following example:

let shapeLayer = CAShapeLayer()
let layer: CALayer = shapeLayer
let reactiveShapeLayer = runtime.get(shapeLayer)
let reactiveLayer = runtime.get(layer)
// reactiveShapeLayer !== reactiveLayer

Note that even though we're using the same shape layer instance, we get a different reacitve object instance depending on the type of the variable we pass to runtime.get. This will lead to unexpected behavior in practice and we should consider alternative solutions to this.

observer.state(.atRest)

spec: https://material-motion.github.io/material-motion/starmap/specifications/streams/operators/$._map

We currently just silently ignore the Core Animation events if we don't support it. This will likely result in weird behavior in certain situations, but we need to audit the code base and identify where and how this is a problem.

This will remove the need for the optional initialVelocity argument for non-spring animations.

For example, if I write to a ReactiveUIView's backing ReactiveCALayer's position property the ReactiveUIView's center property should be updated as well (and vice versa).

A solution might be to use the layer's property directly if we can, and write a wrapper around it when it's not a 1:1 map:

public lazy var alpha: ReactiveProperty<CGFloat> = {
  return self.reactiveLayer.opacity
}()

public lazy var center: ReactiveProperty<CGPoint> = {
    let view = self.view
    let property = ReactiveProperty(initialValue: view.center,
                                    write: {
                                      // TODO: Adjust depending on anchor point
                                      self.reactiveLayer.position.value = $0
                                    }, coreAnimation: {event in
                                      self.reactiveLayer.position.coreAnimation(event) })
    let subscription = self.reactiveLayer.position.asStream().subscribe(next: { position in
      // TODO: Adjust depending on anchor point
      if position != property.value {
        property.value = position
      }
    }, state: { _ in }, coreAnimation: { _ in })
    self.subscriptions.append(subscription)
    return property
}()

Tossable is currently recreating Draggable's stream logic rather than reusing it. This means that if/when we add a compose api to Draggable, Tossable won't benefit from it.

Consider the following interaction:

let spring = Spring<CGFloat>(threshold: 0.01, system: coreAnimation)
spring.initialVelocity.value = 10
spring.destination.value = 1
runtime.add(spring, to: runtime.get(square.layer).scale)

When using POP, this would behave as expected; the view would scale outward somewhat and eventually settle back at 1. This is because POP looks at the overall energy in the system to determine completeness.

When using Core Animation, however, this animation does nothing. This is because Core Animation thinks of velocity only relative to the distance to be traveled (in this case 0), so the animation ends up nooping.

I'm not sure whether there's a clear fix here, but I'll explore some hackfixes.

This will allow gesture recognizers to be treated as streams more easily.

It attempts to map the additive values, resulting in values that aren't compatible with the additive animation.

To resolve this we may need to store the pre-additive information in the animation channel and allow map to affect this. We can then calculate the additive information when the animation is committed to a layer.

Please add a comment explaining why someObject is needed for POP to do its thing.