abort() - Abort Signal

[mrWh1te]

This BotAction would return a Promise that resolves a signal like:

{
  brand: 'abort-signal'
  value: 'actions runner'
}

When a BotAction returns an object like this, the actions runner will check the returned value for matching this signal and if it is, it doesn't process any more actions.

The action runners would then check every action's return value except the last action, since that can just return up the context to the higher runner to kill that instead.

This would effectively change chain()() and the default BotAction to return Promise<void> or Promise<KillSignal>, unless killing an actions runner is a pipe only feature....

It would be handy with the switchPipe() concept as a means to kill the actions runner, but in this case, if a case() returned a signal that it ran (therefore had at least one matching value, to cause it to run its actions) -- a break; equivalent.

[mrWh1te]

This would effect a new minor release ie 2.1.0

[mrWh1te]

{
  brand: 'Signal'
  type: 'abort'
  value: a PipeValue
}

similar to Pipe object

[mrWh1te]

Ideas

1. abort higher order line
2. abort higher order lines by optional levels count (number of higher-order levels to go in then abort)
3. abort higher order line(s) and provide a new Pipe value for line not broken
   • ie you are 5 levels deep in assembled nesting, and you break 2 levels up, so your current and the next one, but you return a special signal from the 2nd level to the 3rd (from the bottom - 1st), that doesn't say abort your line, but basically one child line (1 BotAction assembled representing another line, a sub-line) was aborted and now its provided a new value to pipe into the next

1 & 2 would be supported in Chain and the optional pipeValue? would be supported by Pipes only

[mrWh1te]

{
  brand: 'Abort_Signal'
  assembledLines: 1 // default is 1, the assembled line that the BotAction is in who returned this object
  pipeValue?: a PipeValue
}

edit: implemented as AbortLineSignal type in #66

Special case added, assembledLines = 0, which aborts the entire bot with whatever optional pipeValue provided

[mrWh1te]

Trying to think of other "signals" besides "aborting" that could be useful for an assembled BotAction to "communicate" with the BotAction that assembled it...

Edit:
One idea I have is dynamic assembly. So you emit a signal to prepend a (...BotActions) array to the assembler before the next sibling BotAction is ran, but that sounds like an anti-pattern where things get messy (resulting flows (composed BotAction's) are spread vertically in horizontal slices, unnecessarily complicating it), decreasing code readability, increasing efforts to maintain...

Edit2:
Maybe a notification? Something state related? But with state()() and injectMap()()...

Edit3:
Technically a Pipe object could be considered a "signal"

[mrWh1te]

In the spirit of maximizing code value, I'm leaning towards the more static #36 (comment) over the more dynamic #36 (comment)

There's more time needed to write the dynamic solution, its unit-tests, maybe more bug fixes since it's slightly more complicated, etc when it might not be used at all.

Also, making it dynamic opens the door to patterns that reduce the declarative nature of the system. One of the aspects of the declarative nature in Botmation is the order of the BotActions assembled is maintained as a truth one can rely on ie while quickly skimming code. If I were to add dynamic assembly via "signals", then the order can be "spliced" with "random" BotAction's from a deeper context. That harms the reliability of the order of BotAction's always being true, therefore harming one's ability to quickly skim code, read code therefore maintain code, etc.

Readability is important. If you can make your code predictable, even better.

[mrWh1te]

Ideas

4. within switchPipe()(), switchPipe reads the signal but does not fulfill its duties exactly. Instead, it breaks its assembled line of BotAction's only if a case or more has ran

Therefore, case()() needs to return a "signal" to "Pipe" as to whether or not it ran its assembled actions aka had a matching case(s)

For simplicity, case()() is always ran inside a Pipe, therefore, we can just return a boolean value (TRUE = ran actions, FALSE = no matching cases, no running) instead of doing a dynamic signal solution.

[mrWh1te]

Therefore, the break BotAction is for 1 thing, returning a signal to its assembler to break. Ultimately, it's up to the assembler how to handle the signal

[mrWh1te]

Tip break is a reserved JS word.... need a new word

Similar to if in givenThat()() BotAction

Edit: abort() implemented in #66

[mrWh1te]

Abort Signal support built into assembling BotAction's in PR #66

• use processAbortLineSignal() helper
• use createAbortLineSignal() helper
• use abort() BotAction