X
X
Xip
Search…
State Options
In your FlowMap, each state may also specify certain options. Some options expose built-in Xip functionality, while others are completely custom and can be referenced by your code.
1
class FlowMap
2
3
include Xip::Flow
4
5
flow :hello do
6
state :say_hello
7
state :get_hello_response, fails_to: :say_hello
8
state :say_hola, redirects_to: :say_hello
9
end
10
11
flow :goodbye do
12
state :say_goodbye, re_engage: false
13
end
14
15
flow :interrupt do
16
state :say_interrupted
17
end
18
19
flow :unrecognized_message do
20
state :handle_unrecognized_message
21
end
22
23
flow :catch_all do
24
state :level1
25
end
26
27
end
Copied!
We see three states have options defined: get_hello_response, say_hola, and say_goodbye.

fails_to

The fails_to option is one of the built-in Xip state options. By default, it's used in the CatchAllsController to specify where a user should be sent in the event of an error. We cover this more in the CatchAll docs, but in the get_hello_response state above, if Xip encounters an error the fails_to option declares the user to be sent to the say_hello state of the same flow.
The fails_to value can also be a string if you wish to specify a different flow. So for example:
1
state :get_hello_response, fails_to: 'goodbye->say_goodbye'
Copied!
If Xip encounters an error in this state, it will be sent to the say_goodbye state of the goodbye flow.

redirects_to

The redirects_to option is useful when you're performing a rename of a state and the bot has already been deployed to production. Your production users may have existing sessions attached to the state you are renaming. If you were to perform a state rename without attaching a redirects_to to the old state name, the user will receive an error the next time they message your bot.
For the redirects_tovalues, you can use state names as well as the "flow->state_name" convention like in fails_to.

Custom Options

In addition to the built-in Xip state options, you are able to define your own. This is helpful for cases where you want to define metadata for a set of states but don't want to define that logic within the controllers.
In the example FlowMap above, we've defined a re_engage option on the say_goodbye state. If we pretend our bot re-engages leads after a period of time, this option would be useful for allowing us to declare states for which we do not want re-engagements to be sent. In this case, the user has reached the end of the bot and so we don't want to send them any re-engagements.
You can access these custom state options via the opts attribute for the state specification.
1
state_spec = FlowMap.flow_spec[:goodbye].states[:say_goodbye]
2
state_spec.opts.present? && state_spec.opts[:re_engage]
Copied!
Here state_spec.opts[:re_engage] contains the value true. The hash key will correspond to what you named your option in the FlowMap.
Last modified 9mo ago
Copy link