Branch as core primitive

[nicpottier]

I propose we need a branching operation that is more than just an if (only because that is a common case and will significantly reduce complexity)

As a shwag, perhaps something like:

{
  "type": "branch",
  "uuid": "uuid-blah",
  "outputs": [
    {  
      "uuid": "uuid-output-1",
      "test": "contact.age < 13",
      "destination": "uuid-dest-1"
    },
    {
      "uuid": "uuid-output-2",
      "test": "contact.age < 18",
      "destination": "uuid-dest-2"
    },
    {
      "uuid": "uuid-output-2",
      "test": "contact.age >= 18 && contact.age < 65",
      "destination": "uuid-dest-3"
    },
    {
      "uuid": "uuid-output-3",
      "test": "1",
      "destination": "uuid-dest-3"
    }
  ]
}

Semantics would be that the tests are evaluated one by one and the first "truthy" result that matches will cause the flow to continue from there.

Discussion points:

1. In RapidPro our tests are structured, ie, closer to:

{ "operand": "contact.age",
   "test": { "type": "lt", "test": "18" } }

This is nice when building tests in the UI but strikes me as maybe overkill if we are trying to build out of primitives if we expect our expression language to be, well, expressive. The downside is that editors need to parse the tree if they want to build UIs around this, but I think that's ok. (and they can always punt if they don't know how to build the UI and just show the raw expression)

1. Do branches need labels and such (and associated localization)? From a UI perspective that sure is nice in that you can describe these tests.
2. Should the branching block output something to the session state? Seems that might be useful if the user wants to save the result later.

CC: @rowanseymour @ericnewcomer

[nicpottier]

Another consideration: especially the form people out there like the idea of more than one test matching.. IE, they said, "a" "b" and "c" of options "a", "b", "c", "d", "e". Does having a different "model" to capture these make sense?

My opinion would probably be that that isn't a branching operation but something different.

[markboots]

Added some proposals above. They don't address the the question of labels and localization specifically, except for the labels already built into each block and each exit (at the general level).