Update reactive docs

- Relates spring-projects#742

Author: jvalkeal

docs/src/reference/asciidoc/appendix-reactormigration-examples.adoc

@@ -0,0 +1,5 @@
+=== Reactive Examples
+While most of an examples are still same, we've overhauled some of them and
+created some new:
+
+* Tunrstile Reactive <<statemachine-examples-turnstilereactive>>

docs/src/reference/asciidoc/appendix-reactormigration.adoc

@@ -4,9 +4,11 @@
 Main task for a work for `3.x` has been to both internally and externally to move and change
 as much as we can from imperative code into a reactive world. This means that some
 of a main interfaces has added a new reative methods and most of a internal execution locig
-has been moved over to handled by a reactor. Essentially what this means is that thread handling
-is considerably different compared to `2.x`. Following chapters go throught all these changes.
+(where applicable) has been moved over to handled by a reactor. Essentially what this means is that thread handling model is considerably different compared to `2.x`. Following chapters
+go throught all these changes.
 
 include::appendix-reactormigration-communicating.adoc[]
 
 include::appendix-reactormigration-threading.adoc[]
+
+include::appendix-reactormigration-examples.adoc[]

docs/src/reference/asciidoc/sm-actions-reactive.adoc

@@ -0,0 +1,35 @@
+[[sm-actions-reactive]]
+=== Reactive Actions
+Normal `Action` interface is a simple functional method taking `StateContext`
+and returning _void_. There's nothing blocking here until you block
+in a method itself and this is a bit of a problem as framework cannot
+know what's exactly happening inside of it.
+
+====
+[source,java,indent=0]
+----
+public interface Action<S, E> {
+	void execute(StateContext<S, E> context);
+}
+----
+====
+
+To overcome this issue we've internally changed `Action` handling to
+process a plain java's `Function` taking `StateContext` and returning
+`Mono`. This way we can call action and fully in a reactive way to
+execute action only when it's subscribed and in a non-blocking way
+to wait it's completion.
+
+====
+[source,java,indent=0]
+----
+public interface ReactiveAction<S, E> extends Function<StateContext<S, E>, Mono<Void>> {
+}
+----
+====
+
+[NOTE]
+====
+Internally old `Action` interface is wrapped with a Reactor Mono Runnable as it
+shares same return type. We have no control what you do in that method!
+====

docs/src/reference/asciidoc/sm-actions.adoc

@@ -38,3 +38,5 @@ NOTE: `StateContext` is described in <<sm-statecontext>>.
 You can also use a SpEL expression as a replacement for a
 full `Action` implementation.
 // TODO An example would help
+
+include::sm-actions-reactive.adoc[]

docs/src/reference/asciidoc/sm-guards-reactive.adoc

@@ -0,0 +1,35 @@
+[[sm-guards-reactive]]
+=== Reactive Guards
+Normal `Guard` interface is a simple functional method taking `StateContext`
+and returning _boolean_. There's nothing blocking here until you block
+in a method itself and this is a bit of a problem as framework cannot
+know what's exactly happening inside of it.
+
+====
+[source,java,indent=0]
+----
+public interface Guard<S, E> {
+	boolean evaluate(StateContext<S, E> context);
+}
+----
+====
+
+To overcome this issue we've internally changed `Guard` handling to
+process a plain java's `Function` taking `StateContext` and returning
+`Mono<Boolean>`. This way we can call guard and fully in a reactive way
+to evaluate it only when it's subscribed and in a non-blocking way
+to wait it's completion with a return value.
+
+====
+[source,java,indent=0]
+----
+public interface ReactiveGuard<S, E> extends Function<StateContext<S, E>, Mono<Boolean>> {
+}
+----
+====
+
+[NOTE]
+====
+Internally old `Guard` interface is wrapped with a Reactor Mono Function. We have no
+control what you do in that method!
+====

docs/src/reference/asciidoc/sm-guards.adoc

@@ -1,7 +1,7 @@
 [[sm-guards]]
 == Using Guards
 
-As shown in <<statemachine\-config\-thingstoremember>>, the `guard1` and `guard2` beans are attached to the entry and
+As shown in <<statemachine-config-thingstoremember>>, the `guard1` and `guard2` beans are attached to the entry and
 exit states, respectively.
 The following example also uses guards on events:
 
@@ -35,3 +35,5 @@ to return a `Boolean` value to satisfy the `Guard` implementation. This can be
 demonstrated with a `guardExpression()` function that takes an
 expression as an argument.
 // TODO Good spot for an example
+
+include::sm-guards-reactive.adoc[]