[HN Gopher] Stately Editor Public Beta
       ___________________________________________________________________
        
       Stately Editor Public Beta
        
       Author : davidbarker
       Score  : 70 points
       Date   : 2022-02-08 11:57 UTC (1 days ago)
        
 (HTM) web link (stately.ai)
 (TXT) w3m dump (stately.ai)
        
       | tmikaeld wrote:
       | Hm, this is a state factory right, what's the use case for a
       | visual one?
        
         | JohnHaugeland wrote:
         | No, state machines aren't state factories.
         | 
         | State factories are the generators for state pattern.
         | 
         | State machines are constraint systems which govern which states
         | are allowed to transition to one another.
         | 
         | The use case for a visual editor is that as state machines get
         | over a certain complexity (for me, usually around 15 states,)
         | they start getting hard to reason about. Being able to see them
         | helps.
         | 
         | Consider the case of a state machine representing some object's
         | flow through a manufacturing process. There are three lines:
         | one for main process, one for defect repair, and one for pull
         | testing.
         | 
         | Each line has a set of steps going in both directions: one for
         | progress and the other for Toyota Method style step-audits,
         | going in reverse.
         | 
         | It turns out you forgot one of the steps in the defect repair
         | process, near the middle.
         | 
         | If you're looking at this in code, it's down to reading all the
         | text, looking for exceptions, differences, really working it
         | over
         | 
         | If you're looking at this on a diagram, it's two stripes where
         | it should be three, and there's these two half-stripes that
         | shouldn't be there
        
           | RcouF1uZ4gsC wrote:
           | > It turns out you forgot one of the steps in the defect
           | repair process, near the middle.
           | 
           | This is one of the reasons I like programming my state
           | machines in Rust using enums to represent states. If I forget
           | to deal with that state in my match statement, the compiler
           | yells at me.
        
             | JohnHaugeland wrote:
             | Right, but there are two paths, so it will actually be in
             | your match in one direction.
             | 
             | Anyway, it's not that hard to come up with similar examples
             | where a missing link in the mesh is easier to see than it
             | is to read, and that's my core point.
             | 
             | Consider the case of writing out a small connectivity
             | diagram for a near-grid of things. Now everybody but the
             | edge has 4-5 links. One missing in that is brutally hard to
             | find, if it's irregular, but probably still pretty easy to
             | see.
        
         | playpause wrote:
         | From the post (emphasis theirs):
         | 
         | > Our mission is to _make app logic accessible to the entire
         | team_ , including developers, designers, and stakeholders.
         | Using state machines and statecharts as a common visual
         | language, the software development cycle becomes more
         | collaborative, eliminating handoff and tightening the feedback
         | loop.
         | 
         | For me the more interesting benefit is how it might help an
         | individual developer with designing/coding complex machines in
         | the first place. Many devs value instant visual confirmation
         | after each tiny code change, in a tight feedback loop that
         | leads to a smooth, creative flow state. The GUI side of front-
         | end dev is usually done this way in frameworks like Next.js.
         | Using this new Stately editor via its VS Code plugin might
         | create similar conditions when working on core application
         | logic.
        
         | frb wrote:
         | XState is a great state machine library for
         | JavaScript/TypeScript and we're happily using it in production.
         | 
         | For us the visual editor is a great sketching/design tool
         | between engineers and product managers.
        
       | jedisct1 wrote:
       | "Browser not supported - We currently don't support Safari for
       | the visual editor"
       | 
       | Sad :(
       | 
       | I'm not going to use a special web browser just for one web
       | application.
        
         | playpause wrote:
         | It's the first public beta release, after a huge amount of open
         | source work. Hopefully they'll support Safari soon.
         | 
         | If you're a VS Code user, it's also available as a VS Code
         | plugin, which seems more advanced and useful than the browser
         | app is currently anyway. It has bi-directional editing, which
         | looks very useful.
        
         | stronglikedan wrote:
         | > I'm not going to use a special web browser
         | 
         | But Safari is a "special" browser.
        
       | davidkpiano wrote:
       | Hello everyone - David (creator of XState) from Stately here!
       | 
       | Excited (also anxious) to see this on Hacker News. Please keep in
       | mind that it is a public beta: we have many features and
       | improvements planned.
       | 
       | If you have any suggestions, comments, or bug reports, please
       | post them here: https://github.com/statelyai/editor-
       | feedback/issues
       | 
       | EDIT: Also, we host office hours every Friday, where we answer
       | community questions https://www.youtube.com/statelyai
       | 
       | Thanks, and happy diagramming!
        
         | zellyn wrote:
         | A couple of questions:
         | 
         | 1. Which parts are open source? Will it require a commercial
         | license?
         | 
         | 2. I once worked on an already-existing credit card chargebacks
         | system that was horrifically complex, with all kinds of
         | variations and rules and states that play out over weeks or
         | even months. The logic was scattered all around a Rails app,
         | sometimes in clear chunks of business logic, but sometimes
         | something like an `expired?` accessor on a chargeback variant
         | would know the expiry period for that type of chargeback, etc.
         | 
         | I toyed with the idea of trying to pull all the logic out into
         | some kind of non-code representation. Possibly a state machine
         | diagram, possibly a giant spreadsheet (because with real-world
         | payment processing, you can get just about any response when
         | you're in any state, whether it seems valid or not, and you
         | have to choose to do _something_!). Possibly a state machine
         | diagram for the normal path but with a spreadsheet
         | representation for the full cross-product of weird state
         | transitions. Alas (or thankfully), I moved to a different
         | project before I could undertake anything ambitious.
         | 
         | Would Stately let me do that? Move the knowledge of a hideously
         | complex real-world, extended process that had been
         | painstakingly gathered for years and encoded in logic scattered
         | around an application, and let non-programmer, business-level
         | people use that representation to understand and even tweak
         | parameters of the process?
        
           | davidkpiano wrote:
           | 1. XState is open-source and MIT-licensed:
           | https://github.com/statelyai/xstate, as well as the extension
           | https://github.com/statelyai/xstate-vscode and various other
           | tooling. The editor is closed-source.
           | 
           | 2. Really good example - yes, the Stately editor is intended
           | to be the tool for that! Whether it's just diagramming, in
           | the same way you would use any other diagramming tool, to
           | going even further and simulating those diagrams or even
           | using them directly in your code, the editor is meant to be a
           | tool for making executable diagrams where you can also
           | document and share complex logic.
        
         | pbowyer wrote:
         | Nice work! Anything that helps visualise state I'm happy to
         | see.
         | 
         | Reading the linked article I'm unclear: does Stately generate
         | output that we run with XState? Or is it a SaaS where we design
         | and run the state machine (a bit like Camunda provides for
         | running BPMN diagrams)?
         | 
         | If not already present, a visual runner would be awesome - like
         | https://github.com/bpmn-io/bpmn-js-token-simulation allows, to
         | explore the state.
         | 
         | Edit: looking at the Visualizer I think you've already got a
         | visual runner - I click my way through and see/choose the
         | options at each stage. Cool!
        
       | gampleman wrote:
       | > Browser not supported. We currently don't support Safari for
       | the visual editor. We support Chrome, Edge and Firefox.
        
         | DiabloD3 wrote:
         | Not seeing an issue here. Safari often lags behind published
         | standards, and is nearly impossible to test for (due to Apple
         | being developer hostile).
        
       | gherkinnn wrote:
       | Nice. Most UI is a state machine. Whether you're explicitly
       | modelling it as such or nor not, doesn't matter.
       | 
       | Excellent work on the side of the XState devs.
        
       | polyterative wrote:
       | Looks awesome. Gotta try it later
        
       ___________________________________________________________________
       (page generated 2022-02-09 23:02 UTC)