Building a Responder Chain Using the SwiftUI View Hierarchy
Harnessing EnvironmentValues to easily respond to events generated throughout the view hierarchy
Over the past 10 years I’ve spent a lot of time answering questions in StackOverflow, and a question I see very often is a flavor of:
How do I trigger an event in class
Afrom a function in classB?
This may seem like a simple question for a seasoned developer, after all there are multiple ways we can go about this, we can use delegates, callbacks, notifications, etc., but it’s still a situation that we encounter often, and the farther apart that the two objects are, the more complex it is to communicate between them.
Part of the challenge is to implement this in a way that is scalable and maintainable. You could create an app where every event is sent via NotificationCenter, but you’ll be knocking your head on your desk soon enough.
Enter Responder Chains
A responder chain is a design pattern where responder objects form a “chain”. Events are generated in one of the “links” or “nodes” of the chain, and the node determines if it can handle the event or not. If it cannot handle the event, the event is sent to the next node in the chain. This process continues until a node can handle the event, or the end of the chain is reached.
An object-delegate relationship is a trivial example of this pattern. The object creates an event that it can’t handle itself, so the event is sent to the next node in the chain, which is the delegate. A more complex example is the UIResponder chain.
Explicit responder chains are not super common in iOS development, probably because most of the core building blocks of UIKit, like UIViewController and its subclasses, make it really easy to build without one.
With SwiftUI, however, every object is linked to the root view via the View Hierarchy, which means that the overall structure we need to build a responder chain is already in place, all we need to add are the responders and the events.
The SwiftUI View Hierarchy
An interesting property of the SwiftUI View Hierarchy is that some of its values, like the Environment and EnvironmentObjects, are passed down the hierarchy until they are replaced. We can use this, especially the Environment, to register our responders.
To make things a little bit more visual, this is the hierarchy that would be generated from this simple view. Notice how modifiers, likeforegroundColor, create a node that is a parent to the view they are modifying.
SwiftUI Environment
Environment values can seem intimidating at first because they are often used for system actions, like dismissing a sheet, and adding our own requires extending a system type, EnvironmentValues. It’s perfectly safe to do so, though, and since they can be any kind of type, their Type can be a closure.
With this value in place, any view can read our custom environment value, and also set a new value to it. Since the value we added is a closure, our view can also call this closure.
Creating a Responder
Earlier we mentioned that a responder has the responsibility to determine if it can handle an event or not. Our views will register themselves as responders by registering their own eventClosure into the environment.
Any child views that call eventClosure will be triggering our view’s handler, as long as an intermediate view hasn’t replaced it. If our view determines that it cannot handle the event, it can use the closure it read from the environment, which will come from a parent responder, to allow the event to continue through the chain.
Since this will be a common pattern, we’ll create a ViewModifier that will encapsulate this funcionality.
Our new handler closure has a return type of Any? because that’s how we’re going to determine if the event was handled or not. If the returned value is nil, the event will be considered handled, if the returned value is anything else, that value will be sent up the chain.
Views can now register themselves as responders by calling our modifier and passing a handler closure.
Sending an Event
Triggering an event is a lot simpler, all we need to do is to read the eventClosure from the environment and call it with any value.
A simple but complete example would look like this:
An important detail is that for a responder to be able to receive an event, the source of the event has to be a direct descendant of the responder.
In practice this means that our responders will usually be registered at the root node of each feature or screen.
Scalable and Maintainable
One of the more common ways of triggering events from a child view in SwiftUI is passing a closure as an argument, like you would with a Button. When the view that is responsible from calling that closure gets deeper in the view hierarchy, this closure has to be carried by multiple intermediate views.
Our approach is much more maintainable because only the responder and trigger views need to know about the event. This means that our hierarchy can be modified without having to “carry” this closure through multiple levels.
Thanks to this, our approach is also scalable, and creating an event is as easy as defining a new type. No need to add a new environment value for every event.
Creating a Framework
Following this pattern I created the framework HierarchyResponder, designed to handle events and errors.
This framework takes this concept and expands it by adding specific modifiers to receive, handle, or transform an Event or Error, as well as catching errors.
- Receiving an Event or Error lets you decide if the event was handled or not.
- Handling the Event or Error means it will be consumed, no other options.
- The transforming modifiers let you replace the received Event or Error with a different value.
Another feature is that each modifier has a generic version with a Type parameter that will automatically filter any values that don’t match the type you supplied.
