4 ms·

I always want to use this lib and end up just doing small simple solutions. Does anyone have case examples of when this abstraction helps vs hinders

sebmellen 2y ago
We have a very complex app with many states for each page. A good example is a liveness detection page where we need to check the user’s face position and inform them on how to move it. Formalizing the acceptable state and state transitions is a game changer.
FloNeu 2y ago
Well i feel the abstraction itself doesn’t really hinder… what hinders an i realized costs me lots of time is laying out a good looking machine-layout… the auto-layout for machine introspection still is terrible and currently can’t be used with the layouts in the editors. Also I often end up to having copy the machine json back and forth and this usually requires tweeting as Machine inputs still can’t be mapped using strings and I often end up missing some and then wonder why stuff isn’t working as now errors are automatically caught in the machine. What I really like is that I can visualize my programs and clearly communicate a system using the graphs and delegate the parts that have to filled in. I think it’s also great for documentation and making sure a program is built in a nicely testable way and state is only updated at the appropriate times and places (you need to use an assign action). Model-based testing is also a nice feature… as are the ability to restore machine states at later times using saved state or replaying events. Although I never have done it I enjoy the thought of just taking my machine and put it into another web-fronted and only rebuild the UI by binding the view to state/context and interactions to basic dom events. All in all I think it can have big benefits of having a UML like visualization of your program that can be introspected live at run-time and isn’t immediately outdated because nobody bothers to keep it up to date after a code update (because it is the code). But it surly is a bit of a learning curve… but I encourage you to just try it out beginning with very small machines and build from there. Many of my problems come from just trying to build a giant machine system with many communicating actors from the start. Which totally isn’t needed to assess its features/drawbacks

sebmellen 2y ago

We have a very complex app with many states for each page. A good example is a liveness detection page where we need to check the user’s face position and inform them on how to move it. Formalizing the acceptable state and state transitions is a game changer.

FloNeu 2y ago

Well i feel the abstraction itself doesn’t really hinder… what hinders an i realized costs me lots of time is laying out a good looking machine-layout… the auto-layout for machine introspection still is terrible and currently can’t be used with the layouts in the editors. Also I often end up to having copy the machine json back and forth and this usually requires tweeting as Machine inputs still can’t be mapped using strings and I often end up missing some and then wonder why stuff isn’t working as now errors are automatically caught in the machine. What I really like is that I can visualize my programs and clearly communicate a system using the graphs and delegate the parts that have to filled in. I think it’s also great for documentation and making sure a program is built in a nicely testable way and state is only updated at the appropriate times and places (you need to use an assign action). Model-based testing is also a nice feature… as are the ability to restore machine states at later times using saved state or replaying events. Although I never have done it I enjoy the thought of just taking my machine and put it into another web-fronted and only rebuild the UI by binding the view to state/context and interactions to basic dom events. All in all I think it can have big benefits of having a UML like visualization of your program that can be introspected live at run-time and isn’t immediately outdated because nobody bothers to keep it up to date after a code update (because it is the code). But it surly is a bit of a learning curve… but I encourage you to just try it out beginning with very small machines and build from there. Many of my problems come from just trying to build a giant machine system with many communicating actors from the start. Which totally isn’t needed to assess its features/drawbacks