asdf

README.md

@@ -99,10 +99,6 @@ unsubscriber.Dispose(); // Will only unsubscribe from this subscription
 
 <details closed><summary>How To Unsubscribe Example</summary>
 
-> [!Tip]
-> If you want to receive a single notification, unsubscribe from further notifications by calling the `Dispose()`
-> method on the `IDisposable` object returned by the _**Reactable**_ object. All reactable objects return an unsubscriber object for unsubscribing at a later time.  The unsubscriber is returned when invoking the `Subscribe()` method.  Unsubscribing can be done anytime except in the notification delegates `onReceive`, `onRespond`, and `onReceiveRespond`.
-
 ```cs
 var mySubscription = new ReceiveSubscription(
     id: subId,
@@ -119,11 +115,6 @@ var mySubscription = new ReceiveSubscription(
 
 <details closed><summary>How Not To Unsubscribe Example</summary>
 
-> [!Tip]
-> If an attempt is made to unsubscribe from notifications inside of any of the notification delegates, a `NotificationException` will be
-> thrown.  This is an intentional design to prevent the removal of any internal subscriptions during the notification process.
-> Of course, you can add a `try...catch` in the notification delegate to swallow the exception, but again this is not recommended.
-
 Below is an example of what you _**SHOULD NOT**_ do.
 ```cs
 IDisposable? unsubscriber;
@@ -143,6 +134,15 @@ messenger.Push(subId);
 ```
 </details>
 
+> [!Tip]
+> If you want to receive a single notification, unsubscribe from further notifications by calling the `Dispose()`
+> method on the `IDisposable` object returned by the _**Reactable**_ object. All reactable objects return an unsubscriber object for unsubscribing at a later time.  The unsubscriber is returned when invoking the `Subscribe()` method.  Unsubscribing can be done anytime except in the notification delegates `onReceive`, `onRespond`, and `onReceiveRespond`.
+
+> [!Tip]
+> If an attempt is made to unsubscribe from notifications inside of any of the notification delegates, a `NotificationException` will be
+> thrown.  This is an intentional design to prevent the removal of any internal subscriptions during the notification process.
+> Of course, you can add a `try...catch` in the notification delegate to swallow the exception, but again this is not recommended.
+
 <h3 style="font-weight:bold;color: #00BBC6">One way push notifications</h3>
 
 To facilitate _**one way**_ data transfer through push notifications, you can employ the `PushReactable<TIn>` or `PullReactable<TOut>` types while subscribers utilize the `ReceiveSubscription<TIn>` or `RespondSubscription<TOut>` types for their subscriptions. Setting up and using this approach follows the same steps as in the previous example. In this context, the term one-directional signifies that data exclusively flows in one direction either out from the source to the subscription delegate or from the subscription delegate to the source.