3 ms·

This approach is a big boon to the development of complex UIs. If you are tired of littering your React/Angular/Vue/etc code with a litany of state flags (“isL

by adamkl 6y ago

This approach is a big boon to the development of complex UIs. If you are tired of littering your React/Angular/Vue/etc code with a litany of state flags (“isLoading”, “isError”, etc)[0] take a look at the de facto canonical state chart implementation for JavaScript, XState: https://xstate.js.org/docs/ https://xstate.js.org/docs/ It’s been a joy to work with and can replace other methods of managing state (i.e. redux) while constraining the behaviour of your UI to predictable states and interactions. [0] https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-logic-598i https://dev.to/davidkpiano/no-disabling-a-button-is-not-app-...

davidkpiano 6y ago
Thanks for the kind words about XState (creator here)!
- jen729w 6y ago
  It’s a big boon to the development of tiny simple UIs! I use XState to manage my login state. Not logged in, trying, logged in, log in failed, trying log out, logged out. The thing I love is the confidence the machine gives me. Unless I’ve buggered up completely, it basically can’t be wrong. That’s incredibly reassuring. Thanks for XState and all the work you put in to it. It’s an amazing thing.
  - adamkl 6y ago
    Funny you mentioned login state. I've used it for the exact same thing. I had a "userService" machine (embedded in a React UI) that handled all the legwork of an OAuth2 flow and ended with the user in an "authenticated" state with their details as part of the machine context (for use in any other part of the app via a custom hook). You are absolutely right, it couldn't be wrong. It always just worked exactly the way it was supposed to. I'm now working on a project that handles logins via a set of disconnected boolean flags flowing through redux and it is a mess.
- compscistd 6y ago
  I didn’t know a thing about state machines and lately would deprioritize your xstate frontendmasters course on my learning queue just out of ignorance. For whatever reason, I just watched your React Rally video and I can think of a bunch of projects where state machines would help get the UI in order! A “legacy” ui we have (much older than a week) has these state flags (and then some): IsConfirmed IsSent IsSentAndConfirmed IsDraft IsLoading IsInTheEther IsError IsNaN I want to rewind the clock for a redo on that mega component but I suppose refactoring will have to do. Again, thank you for that great talk!
amelius 6y ago
I just tried to read that code, and perhaps I'm missing something, but wouldn't coroutines/generators be a much better approach of keeping state confined to a local process, and wouldn't that make the code for managing state look more like normal code?
- davidkpiano 6y ago
  Sure, but then you're missing out on the ability to visualize your states and transitions, much less statically analyze your state machines, generate tests for them, etc. etc. There's a lot of potential goodness that you lose when you drop down to "normal code" as opposed to a formalized structure.
  - adamkl 6y ago
    This is one of the things that is preached pretty often in the Clojure community: it’s all about the data Describing your application behaviour in data not only allows for all sorts of static analysis (as David mentioned above) but also the ability to change the behaviour without changing code. You could describe multiple different workflows in your application as different state machines, save them to a data store, and load them up dynamically depending on the situation/user. I’m going off topic, but this approach goes beyond state machines. Focusing on a data driven approach allows you to do some pretty interesting stuff, like designing whole APIs and UIs using data only: https://youtu.be/BNkYYYyfF48 https://youtu.be/BNkYYYyfF48
    - stainforth 6y ago
      Is Clojure better for applying linting to more benefit than other languages then?
gregwebs 6y ago
I developed my own statechart lib many years ago (before React, but I used it with Angular) and used it for the high-level state that drove the application. It worked really well. Redux, etc have always seemed like a step backwards for high-level application state. https://github.com/gregwebs/statetree https://github.com/gregwebs/statetree

by adamkl 6y ago

davidkpiano 6y ago

Thanks for the kind words about XState (creator here)!

jen729w 6y ago
It’s a big boon to the development of tiny simple UIs! I use XState to manage my login state. Not logged in, trying, logged in, log in failed, trying log out, logged out. The thing I love is the confidence the machine gives me. Unless I’ve buggered up completely, it basically can’t be wrong. That’s incredibly reassuring. Thanks for XState and all the work you put in to it. It’s an amazing thing.
- adamkl 6y ago
  Funny you mentioned login state. I've used it for the exact same thing. I had a "userService" machine (embedded in a React UI) that handled all the legwork of an OAuth2 flow and ended with the user in an "authenticated" state with their details as part of the machine context (for use in any other part of the app via a custom hook). You are absolutely right, it couldn't be wrong. It always just worked exactly the way it was supposed to. I'm now working on a project that handles logins via a set of disconnected boolean flags flowing through redux and it is a mess.
compscistd 6y ago
I didn’t know a thing about state machines and lately would deprioritize your xstate frontendmasters course on my learning queue just out of ignorance. For whatever reason, I just watched your React Rally video and I can think of a bunch of projects where state machines would help get the UI in order! A “legacy” ui we have (much older than a week) has these state flags (and then some): IsConfirmed IsSent IsSentAndConfirmed IsDraft IsLoading IsInTheEther IsError IsNaN I want to rewind the clock for a redo on that mega component but I suppose refactoring will have to do. Again, thank you for that great talk!

amelius 6y ago

I just tried to read that code, and perhaps I'm missing something, but wouldn't coroutines/generators be a much better approach of keeping state confined to a local process, and wouldn't that make the code for managing state look more like normal code?

davidkpiano 6y ago
Sure, but then you're missing out on the ability to visualize your states and transitions, much less statically analyze your state machines, generate tests for them, etc. etc. There's a lot of potential goodness that you lose when you drop down to "normal code" as opposed to a formalized structure.
- adamkl 6y ago
  This is one of the things that is preached pretty often in the Clojure community: it’s all about the data Describing your application behaviour in data not only allows for all sorts of static analysis (as David mentioned above) but also the ability to change the behaviour without changing code. You could describe multiple different workflows in your application as different state machines, save them to a data store, and load them up dynamically depending on the situation/user. I’m going off topic, but this approach goes beyond state machines. Focusing on a data driven approach allows you to do some pretty interesting stuff, like designing whole APIs and UIs using data only: https://youtu.be/BNkYYYyfF48 https://youtu.be/BNkYYYyfF48
  - stainforth 6y ago
    Is Clojure better for applying linting to more benefit than other languages then?

gregwebs 6y ago

I developed my own statechart lib many years ago (before React, but I used it with Angular) and used it for the high-level state that drove the application. It worked really well. Redux, etc have always seemed like a step backwards for high-level application state. https://github.com/gregwebs/statetree https://github.com/gregwebs/statetree