Flatten the Interaction types down to a single Interaction protocol.
ClosedPublic

Authored by featherless on Thu, Mar 9, 1:55 AM.

Details

Summary

This new protocol is abstract over the target type, T. This diff flattens ViewInteraction and PropertyInteraction into a single protocol, greatly simplifying the overall type system and also making it possible for interactions to support novel target types.

This change introduces a feature regression: interactions can no longer support multiple target types via overloads. In practice, I found that this actually cleaned up runtime.add call sites (e.g. springs can't be added to views anymore, they must be explicitly added to a property), so I'm not particularly concerned about this regression.

If we do find that it's important for an interaction to support multiple distinct target types, then we can introduce variant Interaction types, e.g. InteractionVariant1, InteractionVariant2, etc... with corresponding runtime APIs.

Diff Detail

Repository
rREACTIVEMOTIONSWIFT reactive-motion-swift
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
featherless created this revision.Thu, Mar 9, 1:55 AM
chuga accepted this revision.Fri, Mar 10, 11:48 AM
chuga added a subscriber: chuga.
chuga added inline comments.
src/MotionRuntime.swift
155

just curious, why isn't this [Interaction]?

This revision is now accepted and ready to land.Fri, Mar 10, 11:48 AM
featherless added inline comments.Fri, Mar 10, 11:59 AM
src/MotionRuntime.swift
155

Because Interaction is a generic protocol. Arrays expect that they'll have a predefined shape, so we'd need to create an AnyInteraction class here that provides a concrete sub-type.

Given that this is a private variable I'm not particularly concerned about ensuring type correctness here, so opted to just use the Any type.

This revision was automatically updated to reflect the committed changes.