You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation
Right now the PubSub handlers are split into three separate closures, with the subscribe/unsubscribe handlers being optional. This won't play well with AsyncStream for being able to respond to all events that a PubSub subscription can cause.
Additionally, the current structure is very verbose in code to maintain - but also adds complexity to developers who are first getting started to understand the lifecycle of PubSub events.
Changes
- Add: New `RedisPubSubEvent` enum that captures the subscribe, unsubscribe, and message lifecycle events
- Add: New `RedisPubSubEventReceiver` that combines the previous 3 closure types
- Add: Dedicated DocC Symbol Extension file for `RedisPubSubHandler`
- Change: `RedisClient.subscribe` and `RedisClient.psubscribe` method signatures to only require a single unlabeled closure
- Rename: `RedisUnsubscribeEventSource` to `RedisPubSubEvent.UnsubscribeEventSource`
- Remove: `RedisSubscriptionMessageReceiver`, `RedisSubscriptionChangeDetails`, `RedisSubscribeHandler`, and `RedisUnsubscribeHandler` types
Result
Developers should have a much easier time getting started and understanding PubSub with assistance from the compiler with types to understand
what they're being given and what's available to them as information to make more informed decisions in their app logic.
/// A list of patterns or channels that a Pub/Sub subscription change is targetting.
67
61
///
68
-
/// See `RedisChannelName`, [PSUBSCRIBE](https://redis.io/commands/psubscribe) and [SUBSCRIBE](https://redis.io/commands/subscribe)
62
+
/// See ``RedisChannelName`` or the Redis documentation on [PSUBSCRIBE](https://redis.io/commands/psubscribe) and [SUBSCRIBE](https://redis.io/commands/subscribe).
69
63
///
70
64
/// Use the `values` property to quickly access the underlying list of the target for any purpose that requires a the `String` values.
@@ -97,33 +91,6 @@ public enum RedisSubscriptionTarget: Equatable, CustomDebugStringConvertible {
97
91
}
98
92
99
93
/// A channel handler that stores a map of closures and channel or pattern names subscribed to in Redis using Pub/Sub.
100
-
///
101
-
/// These `RedisPubSubMessageReceiver` closures are added and removed using methods directly on an instance of this handler.
102
-
///
103
-
/// When a receiver is added or removed, the handler will send the appropriate subscribe or unsubscribe message to Redis so that the connection
104
-
/// reflects the local Channel state.
105
-
///
106
-
/// # ChannelInboundHandler
107
-
/// This handler is designed to be placed _before_ a `RedisCommandHandler` so that it can intercept Pub/Sub messages and dispatch them to the appropriate
108
-
/// receiver.
109
-
///
110
-
/// If a response is not in the Pub/Sub message format as specified by Redis, then it is treated as a normal Redis command response and sent further into
111
-
/// the pipeline so that eventually a `RedisCommandHandler` can process it.
112
-
///
113
-
/// # ChannelOutboundHandler
114
-
/// This handler is what is defined as a "transparent" `NIO.ChannelOutboundHandler` in that it does absolutely nothing except forward outgoing commands
115
-
/// in the pipeline.
116
-
///
117
-
/// The reason why this handler needs to conform to this protocol at all, is that subscribe and unsubscribe commands are executed outside of a normal
118
-
/// `NIO.Channel.write(_:)` cycle, as message receivers aren't command arguments and need to be stored.
119
-
///
120
-
/// All of this is outside the responsibility of the `RedisCommandHandler`,
121
-
/// so the `RedisPubSubHandler` uses its own `NIO.ChannelHandlerContext` being before the command handler to short circuit the pipeline.
122
-
///
123
-
/// # RemovableChannelHandler
124
-
/// As a connection can move in and out of "PubSub mode", this handler is can be added and removed from a `NIO.ChannelPipeline` as needed.
125
-
///
126
-
/// When the handler has received a `removeHandler(context:removalToken:)` request, it will remove itself immediately.
``RedisPubSubEventReceiver`` closures are added and removed using methods directly on an instance of this handler.
4
+
5
+
When a receiver is added or removed, the handler will send the appropriate subscribe or unsubscribe message to Redis so that the connection
6
+
reflects the local Channel state.
7
+
8
+
## ChannelInboundHandler
9
+
This handler is designed to be placed _before_ a ``RedisCommandHandler`` so that it can intercept Pub/Sub messages and dispatch them to the appropriate
10
+
receiver.
11
+
12
+
If a response is not in the Pub/Sub message format as specified by Redis, then it is treated as a normal Redis command response and sent further into
13
+
the pipeline so that eventually a ``RedisCommandHandler`` can process it.
14
+
15
+
## ChannelOutboundHandler
16
+
This handler is what is defined as a "transparent" `NIO.ChannelOutboundHandler` in that it does absolutely nothing except forward outgoing commands
17
+
in the pipeline.
18
+
19
+
The reason why this handler needs to conform to this protocol at all, is that subscribe and unsubscribe commands are executed outside of a normal
20
+
`NIO.Channel.write(_:)` cycle, as message receivers aren't command arguments and need to be stored.
21
+
22
+
All of this is outside the responsibility of the ``RedisCommandHandler``,
23
+
so the ``RedisPubSubHandler`` uses its own `NIO.ChannelHandlerContext` being before the command handler to short circuit the pipeline.
24
+
25
+
## RemovableChannelHandler
26
+
As a connection can move in and out of "PubSub mode", this handler can be added and removed from a `NIO.ChannelPipeline` as needed.
27
+
28
+
When the handler has received a `removeHandler(context:removalToken:)` request, it will remove itself immediately.
0 commit comments