This repository has been archived by the owner on Aug 30, 2023. It is now read-only.
Add support for on-demand transitions #39
Labels
Comments
jverkoey
added a commit
that referenced
this issue
Sep 13, 2017
Closes #31. This is a breaking change due to removal of APIs and changing of nullability annotations on existing APIs. This PR allows a client to associate multiple `Transition` instances with a single view controller transition. When a transition is initiated, each `Transition` instance will be provided the same transition context. This allows us to build smaller transition types, such as "FadeTransition" or "SlideTransition" which each accept a target view. These transitions can then be combined to create a "slide and fade in transition" like so: ```swift modalViewController.transitionController.transitions = [ FadeTransition(target: .foreView), SlideUpTransition(target: .foreView) ] ``` Some open questions this change has introduced: - How does view duplication work across transitions? Ideally if a view were duplicated by one transition it would not be re-duplicated by another, but ensuring that all transitions access views in a safe manner would require adoption of a convention, e.g. `context.resolvedView(for: view)`, which would be routed through a shared view duplicator. - Who is responsible for associating transitions with a given view controller transition? There are potentially three actors who might be interested in associating Interaction instances. This topic is discussed in #39. - How might a client easily build a transition that is composed of other transitions? This may warrant a follow-up feature change, possibly with the introduction of a `TransitionWithChildTransitions` protocol that allows the parent transition to return an array of child transitions.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Generally-speaking, there are three categories of transition type:
Our current
transitionController.transitionAPI doesn't necessarily make it easy for types 2 or 3 to associate Transition types during a transition. For example, during a contextual photo transition (type 1), our fore view controller may want to slide in its bottom toolbar (type 3). The contextual photo transition was likely configured by the back view controller when it created the presented view controller, but the back view controller shouldn't necessarily be forced to configure the toolbar transition as well.Ideally, the fore view controller could react to a transition occurring and add extra transitions when it deems necessary. The back view controller could also provide similar facilities.
With this sort of approach we may find that it's actually beneficial to remove the
transition =API and prefer a querying API instead.The text was updated successfully, but these errors were encountered: