tomasd
commented
6 years ago Hi Matthew,
there's no strict restriction on the number of statecharts in application. Strict decision is done in statecharts.re-frame/initialize, statecharts.re-frame/process-event, so if you do not use those functions you are free to put statecharts state/configuration in different places of re-frame DB.
But I prefer to have only 1 configuration/state for statechart. I find it easier to work with it. You don't need to dispatch different events to different statechart roots. You still can have separate "orthogonal" statecharts which can be bound under root component (AND type) statechart. This way you just fire event and direct it to the statechart and the right state will process it.
So to answer your questions:
It seems like this library is meant to have a single root state for the entire application - is that a fair read? It's meant to live in a single key in the re-frame db, right?
Re-frame integration (statecharts.re-frame namespace) works with this assumption
For example, if you took the traffic lights example, and had that as a component in your app - would you expect that to be part of the "tree"?
Yes, I'd put it under top level state where it does make sense. For instance if there are top level states :authenticated-user/:anonymous-user and you need traffic lights only for authenticated-users, I'd put it as a child. Otherwise if it's app wide aspect, I'd create :traffic-light and :user-status top level statecharts (under AND root) and put :authenticated-user/:anonymous-user under :user-status. It always depends on the behavior you'd like to model.
For some reason, I feel like there could multiple statechart "roots" in the app - would you consider that being implemented as a top-level state that had :type of :and?
Yes, there could be multiple roots, but then you need to dispatch events to them. As stated above, it's probably easier to put multiple roots as children of the AND type root statechart.
Thanks for your interest and feel free to ask more questions or suggestions.
hoopes
Hi Tomas,
Sorry to bug you again, I have another question about your library. I've studied the gmail example (to the extent of my abilities...). It seems like this library is meant to have a single root state for the entire application - is that a fair read? It's meant to live in a single key in the re-frame db, right?
As I'm building out my application, it seems like there are opportunities for statecharts not necessarily falling into a large state "tree" (for lack of better word). For example, if you took the traffic lights example, and had that as a component in your app - would you expect that to be part of the "tree"? Is the statechart tree intended to be analogous to the structure of the view components?
For some reason, I feel like there could multiple statechart "roots" in the app - would you consider that being implemented as a top-level state that had
:typeof:and?Thanks in advance for any help, it's very much appreciated.