Result Builders

[davdroman]

Complex transitions start getting a little trickier to formulate and read clearly...

Maybe good motivation to introduce result builder syntax.

Before:

extension NavigationTransition {
    static var swing: Self {
        let angle = Angle(degrees: 70)
        let offset: CGFloat = 150
        let scale: CGFloat = 0.5

        return .move(axis: .horizontal).combined(
            with: .asymmetric(
                push: .asymmetric(
                    insertion: [.rotate(-angle), .offset(x: offset), .opacity, .scale(scale)].combined(),
                    removal: [.rotate(angle), .offset(x: -offset)].combined()
                ),
                pop: .asymmetric(
                    insertion: [.rotate(angle), .offset(x: -offset), .opacity, .scale(scale), .bringToFront].combined(),
                    removal: [.rotate(-angle), .offset(x: offset)].combined()
                )
            )
        )
    }
}

After:

extension NavigationTransition {
    @Builder
    static var swing: Self {
        let angle = Angle(degrees: 70)
        let offset: CGFloat = 150
        let scale: CGFloat = 0.5

        Move(axis: .horizontal)
        OnPush {
            OnInsertion {
                Rotate(-angle)
                Offset(x: offset)
                Opacity()
                Scale(scale)
            }
            OnRemoval {
                Rotate(angle)
                Offset(x: -offset)
            }
        }
        OnPop {
            OnInsertion {
                Rotate(angle)
                Offset(x: -offset)
                Opacity()
                Scale(scale)
            }
            OnRemoval {
                Rotate(-angle)
                Offset(x: offset)
            }
        }
    }
}

[davdroman]

Further thoughts on this. Things are getting clearer and clearer in my mind.

• First off, NavigationTransition must become AnyNavigationTransition, which should be a type eraser around a PrimitiveNavigationTransition protocol, as well as hold the animation value (as of this moment it can be set on any transition, which is awkward).
• AnyNavigationTransition will also stop setting the view hierarchy up. Instead this will be the responsibility of NavigationTransitionAnimatorProvider. It will look inside AnyNavigationTransition and, if it finds a NavigationTransition, it'll perform the setup, however if it only finds a PrimitiveNavigationTransition it'll assume the user is taking full charge of the transition and not do anything in that front.
• PrimitiveNavigationTransition is the base protocol to which all transitions must conform, but most of them will conform to the subprotocol NavigationTransition; as PrimitiveNavigationTransition is, as the name indicates, primitive — it will be allocated for raw UIKit transitions. Meanwhile, result builders come in at NavigationTransition level in order to help composition. This way both worlds are completely separated and the routes are clear: either compose a NavigationTransition atomically, or use a completely custom PrimitiveNavigationTransition. Either way both resolve to the latter type.
• The result builder approach will be similar to that of ReducerProtocols in TCA, with one distinction: Body is not declared on PrimitiveNavigationTransition since it's not composable. Instead, it's declared on NavigationTransition, along with a transition function (a la reduce) for bottom types.
• AtomicTransition also gets reimplemented as a protocol and gets the same result builder treatment to aid composition — with the potential addition of MirrorableAtomicTransition from `Mirror` Transitions #7 later on.
• Finally, remove raw UIKit AtomicTransitions. They really had no place in the API in the first place, and it only leads to confusion. If there's any gap in capability, it should be addressed by improving AnimatorTransientView instead of keeping a shoehorned API alive.

[davdroman]

Done! #19