Can't use event handler by itself about swiftstate HOT 9 CLOSED

Hi, thanks for feedback :)

Actually, adding routes and handlers are totally different concepts.
You should register all routes first to characterize the StateMachine's transition flow before adding any side-effects i.e. handlers.
So, it is meaningless to just add handlers without declaring what routes are available.

In your case, if you want to invoke an "event handler" by .SomeEvent from any states without changing current one, you can add a route that is only available for .SomeEvent:

// add route for "anywhere to anywhere" but only valid when `.SomeEvent` is called
machine.addRouteEvent(.SomeEvent, transitions: [ nil => nil ])

// or, attach eventHandler all together
machine.addRouteEvent(.SomeEvent, transitions: [ nil => nil ], handler: { ... } )

Important thing here is: Adding routes are more important. Handlers are secondary.

(Also, please also note that you can't attach route by addHandler()/addEventHandler() although you can attach handler in addRoute()/addEventRoute())

from swiftstate.

Ah, sorry. There seems to have a bug when I do the above (finished state will be .AnyState).
I will fix this soon.

from swiftstate.

Great, thanks! Let me know if I can help.

And thank you for your feedback. Actually, I use a state machine paradigm for just states and would enjoy the idea of passing events to states -- e.g., machine.addEventHandler(.SomeState, { ... } ).

The state for me is a greater view idea than a button being on / off do you know what I mean? It's in a Loading state or a Showing state or a Searching state etc.. I certainly don't overload the view controller here, but instead employ the VIPER pattern across these major components. I employ a state machine paradigm at the V or view level, whereas the P or presenter is the main director of the view. The view is dumb and merely just moves things around in response to state changes OR events. This makes communication between P and V well-defined with clear-cut split responsibilities.

from swiftstate.

My above mentioned is fixed in #29.
Please check StateMachineEventTests.swift#L89-L112 for more information.

from swiftstate.

#28 (comment)

Maybe you are only interested in current state and not transition.
But actually, you can create the stay-still route i.e. .SomeState => .SomeState and attach handlers to it.

Also, Event is used for grouping state transitons, so it's good idea not to mix with State.

from swiftstate.

Hmm.. I'm not sure what you mean by grouping state transitions. My idea stems from seeing states as templates. These templates can have activity spawned on them via events. Take for example a simple photo editor in which you have an ADD TEXT state. From within that state, you can change fonts by sending events VC ! ("CHANGE_FONT", fontToChangeTo). I'm not too sure what your alternative is? Sure, I can send the same state with some new refresh data embedded within userInfo, but that's not as clean as sending events tightly coupled with their corresponding data.

from swiftstate.

Sorry, I couldn't understand your question...
Is your above question related to the first one?

from swiftstate.

Code looks good. I'm just explaining my paradigm and how your library fits into it. Let me know if you have any questions. Thanks again.

from swiftstate.

All right.
You can create a new issue and explain your idea a bit more detailed,
for example, using StateMachine diagram like
https://en.wikipedia.org/wiki/Finite-state_machine.

Anyway! Thanks for your feedback 😊

from swiftstate.