Switch implementation

[emaglio]

The aim is to have a simple API to be able to recreate a case/when block with TRB.
Here the flowchart of an operation using a Switch macro:

Requirements:

• one branch step in the beginning
• one "track" or whatever (path??) per option
• multiple ends per "path"
• arbitrary connections amongst the "paths" (as an additional feature)

Possible API solution:

class ChargeSwitch < Trailblazer::Operation
      class Braintree < Trailblazer::Activity::Signal; end 
      .....
      
      step Switch(condition: :set_condition) {
        option "stripe",    Trailblazer::Operation::Nested(ChargeStripe)
        option "braintree", :braintree, Output(Braintree, :success) => Track(:braintree)
        option /./,         :unsupported
      }
      
      ......
end

Here the branch where a draft implementation has been done (not the best but the tests are reusable): https://github.com/trailblazer/trailblazer-macro/tree/macro_switch

[emaglio]

https://trailblazerpro.slack.com/archives/C1A3VSLTZ/p1544636191087600

[yogeshjain999]

Hey @emaglio , does this solution seems similar to https://2019.trailblazer.to/2.1/docs/activity.html#activity-wiring-api-path- ? Was the Path idea taken from this ? 😄

[emaglio]

@yogeshjain999 is that solution allows more that 2 options? the Path() solution seems limiting the number of options right?

[yogeshjain999]

@emaglio Yes, we can add more outputs.

step :decide_type,
  Output(:failure) => Path(connect_to: Id(:finalize), &failure_path),                                              
  Output(:success) => Path(connect_to: Id(:finalize), &success_path)

I guess we should document this also in website.

[emaglio]

I don't know @yogeshjain999 that looks really complicated to read.
It would be good to expose a better API where we can easily read what is happening.
For what I remember (which it can be different now), if you want more than success and failure you need to add more End objects, then link those new ends with Outputs? and then bla bla...gets really hard to setup and confusing to ready.
Maybe I'm not up to date with the newly API so please write an activity using as reference the flow chart above using the Output/Path combination so we can see directly how that looks like, what do you think?

[yogeshjain999]

Hmm understood. So the activity for above chart would look like this,

It might be difficult to understand this initially, but I guess over the time it gets easier to look at.
Maybe the simple way to look at the Path() is that it allows,

• Segregating steps into respective tracks within the activity.
• And have different Ends as per those tracks, for easy debugging and endpoint.

BTW - step API inside Path() block needs to support more wiring DSL (Nested, Output etc gives error inside that block as of now 😉).

[emaglio]

Yeah well that doesn’t look too bad at all I think! We should document this properly with a Switch paragraph where we just use this structure.
So for now I would leave this open until we add some documentation?

[yogeshjain999]

Yep, cool.

[apotonick]

I actually don't think that a macro on top of that would be wrong? We could provide it in a separate gem and see how it feels? I wouldn't dare to confront every TRB user with all those wiring details if all they want to have is just a "simple" switch.
The same goes for Iterate, it will just be another macro.

[yogeshjain999]

Hmm, you mean defining macro which uses Path() internally like above ?

I'm not really sure if we should provide another identical way to implement Switch. Instead, getting users familiar with wiring DSL would make them comfortable for implementing any kind of conditional circuit.

[apotonick]

An abstraction using Path() internally would be cool, and with Path() now accepting a block parameter directly it should be quite simple. I do that a lot already internally in endpoint as I am struggling to remember all options. 😆