Flow handlers allow you to register blocks of code to run when "states" are triggered. "States" are automatically checked if an error occurs in an execJsPath, or an interact command. You can also manually trigger checking states with checkFlowHandlers.
When FlowHandlers are checked, the state is checked for all of them at once, and the first one to match will be run. Commands are re-tried after a single flow handler is matched. If they error again, we will retry the flow handlers up to 3 times to correct the state. Any errors occurring in flow handler will bubble up to the current command (otherwise it becomes very difficult to track errors originating in the FlowHandlers).
You can use this feature to:
dismiss a GDPR cookie panel
handle overlays
handle captchas
redirect to the correct pages
Flow Handlers are "implicitly" attached to the active tab. We might need to enhance this feature at some future date to better handle multiple open tabs concurrently, but it didn't feel like a priority for this version.
Some changes to the client library are attached to this change:
The StateMachine handling inherited from AwaitedDom is replaced with "truly private" variables. Any "shared" variables are now using the InternalProperties class that will not be exported out of Client.
The ConnectionManager that previously blurred lines between managing "tabs" for a hero instance and creating a CoreSession is now merged into the Hero class as private state.
The CoreCommandQueue "intercept" concept now supports concurrent registrations (necessary to support multiple FlowHandlers at once)
To help track the active FlowHandlers that change state, the CommandsTable is modified, and a FlowHandlers table is introduced.
FlowHandlers tracks the registrations of flow handlers and gives each an "id". The source location is tracked, and any name given to the handler.
CommandsTable:
The retryNumber of any command that is retried after running the flow handlers
Any active FlowHandler when a command is run, using activeFlowHandlerId. This field can be used to highlight in a timeline which FlowHandler is active for a given set of commands. "Active" refers to the execution of the "Handler"
This PR introduces Flow Handlers.
Flow handlers allow you to register blocks of code to run when "states" are triggered. "States" are automatically checked if an error occurs in an execJsPath, or an interact command. You can also manually trigger checking states with
checkFlowHandlers.When FlowHandlers are checked, the state is checked for all of them at once, and the first one to match will be run. Commands are re-tried after a single flow handler is matched. If they error again, we will retry the flow handlers up to 3 times to correct the state. Any errors occurring in flow handler will bubble up to the current command (otherwise it becomes very difficult to track errors originating in the FlowHandlers).
You can use this feature to:
Flow Handlers are "implicitly" attached to the active tab. We might need to enhance this feature at some future date to better handle multiple open tabs concurrently, but it didn't feel like a priority for this version.
Some changes to the client library are attached to this change:
To help track the active FlowHandlers that change state, the CommandsTable is modified, and a FlowHandlers table is introduced.
retryNumberof any command that is retried after running the flow handlersactiveFlowHandlerId. This field can be used to highlight in a timeline which FlowHandler is active for a given set of commands. "Active" refers to the execution of the "Handler"