abort() - Abort Signal about botmation HOT 10 CLOSED

This would effect a new minor release ie 2.1.0

from botmation.

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

similar to Pipe object

from botmation.

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

from botmation.

{
  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

from botmation.

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"

from botmation.

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.

from botmation.

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.

from botmation.

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

from botmation.

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

Similar to if in givenThat()() BotAction

Edit: abort() implemented in #66

from botmation.

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

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

from botmation.