Skip to content
This repository has been archived by the owner on Aug 30, 2023. It is now read-only.

Add support for decorating transitions #31

Closed
jverkoey opened this issue Jul 20, 2017 · 3 comments · Fixed by #40
Closed

Add support for decorating transitions #31

jverkoey opened this issue Jul 20, 2017 · 3 comments · Fixed by #40
Labels
Feature request

Comments

@jverkoey
Copy link
Contributor

First pass may be to build an example of using the animate alongside APIs.

Second pass may be support for adding multiple transition decorators to a given transition.
@jverkoey
Copy link
Contributor Author

Simple use case: there exists a componentized push back transition. A client wants to use that transition, but also to fade out some other views alongside the transition. The client can't easily modify the componentized transition.

@jverkoey
Copy link
Contributor Author

jverkoey commented Jul 20, 2017 •
edited
Loading

I just tried out the native alongside APIs with a simple transform and it seems that doing so breaks the navigation bar layout, but using a Transition with a Core Animation transform does not. This may be an argument for providing some semblance of a "decorator" API alongside the transitions.

@jverkoey
Copy link
Contributor Author

Some more thinking:

  • Each decorator instance provided for a given transition would be given its own transition context and expected to inform the context of its completion.
  • The transition controller would then aggregate all of these contexts and complete the transition once all decorations have completed.

A rough API might look like this:

vc.transitionController.transitions = [PrimaryTransition(), DecoratorTransition()]

@jverkoey jverkoey mentioned this issue Aug 30, 2017
Merged
jverkoey added a commit that referenced this issue Sep 13, 2017
@jverkoey
Add multi-transition support. (#40)
8653958 
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.
Assignees
No one assigned
Labels
Feature request
Projects
None yet
Milestone
No milestone
1 participant
@jverkoey