switchPipe()() misses casePipe results from return array

[mrWh1te]

Botmation/src/botmation/actions/assembly-lines.ts

Line 162 in 6dd013d

atLeastOneCaseMatched = true

In the event a pipeCase()() returns a MatchesSignal, the results of which need to be added (pushed) unto the results array that is returned in the end

Add test

Reduce push calls

Should it push the signal itself or the pipeValue... or unto the results array that is returned at the end?

[mrWh1te]

switchPipe()() is a piping BotAction and therefore will return a value, an array representing the values returned by each assembled BotAction.

The exception, like for every BotAction since #66, is being aborted, which switchPipe()() has unique abort behavior. The number of assembledLines to abort is dynamic between default 2. It's 1 when at least one assembled pipeCase()() returns a MatchesSignal with at least one match.

When it's aborted, an AbortLineSignal is returned or a PipeValue (depending on the assembledLines count of the AbortLineSignal). So if a pipeCase matches, followed by an abort with 1 assembledLine (and a pipeValue), the AbortLineSignal's pipeValue will be returned. Similar to the other BotAction's, once aborted with no further assembledLines to abort, it returns the pipeValue (default value is undefined) Instead when it's aborted without additional assembledLines to be aborted, instead of returning the AbortLineSignal's pipe value, the pipeValue should be pushed unto the array that is returned. If abort(2), with a pipeCase()() that matched, then return the AbortLineSignal's pipeValue, not the array.

Aborting in switchPipe is different in that it's like a soft-abort, it wants to abort the assembled functionality, but not the returning of the actions' resolved responses. That requires one additional assembledLines to abort... need to think more on this

If it's not aborted, the returned array will consist of PipeValue's and possibly MatchesSignal's.

Did consider returning a MatchesSignal's pipeValue instead of the MatchesSignal object itself, but the MatchesSignal hash-map of matches has useful information that does not to be discarded just yet

[mrWh1te]

Traditional switch/case/break statement:

switch(value){
   case 10:
      // run code
   break; // this is triggered IF case 1 matches
   case 'test':
      // run code
   break; // this is triggered IF case 'test' matches
   default:
      // ran if not break earlier
}

The idea is to copy the flow with switchPipe/casePipe/abort(1)

await pipe()(
   switchPipe(value)( // can be a BotAction to resolve for pipeValue to inject, or just a pipeValue to inject
      pipeCase(10)(
         // run assembled actions if value === 10
      ),
      abort(1), // stops assembled BotActions from running in switchPipe IF a pipeCase() has matched
      pipeCase('test')(
         // run assembled actions if value === 'test'
      ),
      abort() // same as abort(1) as no param fallback sets value to 1
      // default code can be put directly here without pipeCase
   )
)(mockPage)

[mrWh1te]

current concept for switchPipe abort behavior

if an assembled botaction returns an infinite AbortLineSignal(0) then return that

otherwise, if no case matches, process a returned AbortLineSignal by 1 assembledLines (subtract 1 from assembledLines)

then for either no case matches or has matches, upon abortline signal do the following:

0 = dont break line, append abortLineSignal.pipeValue to return array
1 = break line, append abortLineSignal.pipeValue to return array then return array
2+ = dont return array, but return an AbortLineSignal( 1+ ) // reduce count by 1

otherwise proceed like normal (pipe values returned by functions are appended to return array and MatchesSignal is also appended to return array)