add test for events-as-object

[boneskull]

No description provided.

[vstirbu]

The events property of the configuration object is array in the other examples. Do you really need events as an object?

I have some state machines where this approach will not work as they have multiple events having the same name but starting from different states.

[boneskull]

I don't need it this way, but it's less verbose if you don't have multiple events with the same name. I didn't even realize that was supported. So your call whether or not to support it--since it's trivial, why not?

[vstirbu]

Although it is more readable to have the events as an object is not on par feature wise with having it as array (e.g. not being able to have multiple events with same name). For this reason we cannot say that these formats are interchangeable.

However, this is a library and we should maintain a level of flexibility. What about having an eventsLite configuration property that is merged into the events array? This way the users have a clear idea about what are the limitations of this approach.

Although I like the object notation, my main concern here is how to avoid confusion between the two. Do yu have a better way of addressing this issue?

[boneskull]

I have some state machines where this approach will not work as they have multiple events having the same name but starting from different states.

I'd like to understand your use case better. Why do they have the same name? If event foo can be called in states a or b, does this event cause transition to state c in both cases? If so, you could specify multiple "from" states in the event definition, using the object notation:

{
  foo: {
    from: ['a', 'b'],
    to: 'c'
  }
}

But if it doesn't always transition to c (or have a conditional), I'm not sure why it has to be the same name?

[vstirbu]

I have state machines that model the scoring systems in different sports. In this context the events and the state names are taken from the nomenclature of the respective sport. This is a simplified example:

[
 {name: 'end', from: 'Round1', to: ['Break', 'Final'], condition: ... },
 {name: 'end', from: 'Break', to: 'Round2' },
]

Using the array format I have the flexibility to do whatever is needed to implement the rules but also present them in a familiar form to the users.