What are the key takeaways from this Full Stack Radio episode?

Key insights include: **State representation:** Replace boolean variables like isLoading with single status strings (idle, loading, success) to prevent impossible state combinations. Multiple booleans create 2^n possible states when only 5-7 are valid, causing bugs like Reddit showing "no results" while displaying results.; **Event-driven architecture:** Event handlers should only send events (like formSubmitted), not execute logic directly. The state machine determines valid transitions based on current state first, then event type, automatically ignoring invalid actions without if-statement guards protecting edge cases.; **Transition structure:** Implement state machines using nested switch statements that check current state first, then event type second. This inverts typical logic where actions check state, instead making states determine which actions are allowed, eliminating manual edge case handling.

What did State Machines discuss on Full Stack Radio?

David Khourshid explains how finite state machines eliminate impossible UI states by using labeled states instead of boolean flags, preventing bugs like simultaneous loading spinners and displayed data through deterministic state transitions. Key topics include: **State representation:** Replace boolean variables like isLoading with single status strings (idle, loading, success) to prevent impossible state combinations. Multiple booleans create 2^n possible states when only 5-7 are valid, causing bugs like Reddit showing "no results" while displaying results.; **Event-driven architecture:** Event handlers should only send events (like formSubmitted), not execute logic directly. The state machine determines valid transitions based on current state first, then event type, automatically ignoring invalid actions without if-statement guards protecting edge cases..

How long is this episode of Full Stack Radio?

This episode is 54 minutes long. SignalCast provides an AI-generated summary so you can get the key insights in about 3 minutes.

Full Stack Radio

130: David Khourshid - Building Better UI Components with State Machines

December 11, 2019

54 min episode · 2 min read

State Machines

Episode

54 min

Read time

2 min

Topics

Leadership, Design & UX, Software Development

AI-Generated Summary

Published Dec 25, 2025

Key Takeaways

✓State representation: Replace boolean variables like isLoading with single status strings (idle, loading, success) to prevent impossible state combinations. Multiple booleans create 2^n possible states when only 5-7 are valid, causing bugs like Reddit showing "no results" while displaying results.
✓Event-driven architecture: Event handlers should only send events (like formSubmitted), not execute logic directly. The state machine determines valid transitions based on current state first, then event type, automatically ignoring invalid actions without if-statement guards protecting edge cases.
✓Transition structure: Implement state machines using nested switch statements that check current state first, then event type second. This inverts typical logic where actions check state, instead making states determine which actions are allowed, eliminating manual edge case handling.
✓Naming conventions: Name events in past tense describing what occurred (usernameChanged, dogRequested) rather than imperative commands (updateUsername, fetchData). This acknowledges events may not succeed and separates user intent from actual state changes, preventing misleading action names when operations fail.

What It Covers

David Khourshid explains how finite state machines eliminate impossible UI states by using labeled states instead of boolean flags, preventing bugs like simultaneous loading spinners and displayed data through deterministic state transitions.

Key Questions Answered

•State representation: Replace boolean variables like isLoading with single status strings (idle, loading, success) to prevent impossible state combinations. Multiple booleans create 2^n possible states when only 5-7 are valid, causing bugs like Reddit showing "no results" while displaying results.
•Event-driven architecture: Event handlers should only send events (like formSubmitted), not execute logic directly. The state machine determines valid transitions based on current state first, then event type, automatically ignoring invalid actions without if-statement guards protecting edge cases.
•Transition structure: Implement state machines using nested switch statements that check current state first, then event type second. This inverts typical logic where actions check state, instead making states determine which actions are allowed, eliminating manual edge case handling.
•Naming conventions: Name events in past tense describing what occurred (usernameChanged, dogRequested) rather than imperative commands (updateUsername, fetchData). This acknowledges events may not succeed and separates user intent from actual state changes, preventing misleading action names when operations fail.

Notable Moment

Khourshid reveals users frequently encounter stuck UI states but never report bugs because they simply restart the application instead of filing reports, meaning developers remain unaware of state machine defects that visual diagrams would immediately expose.

Know someone who'd find this useful?

Episode Transcript

In this episode of Fullstack Radio, I talked to David Khorshid about how state machines can help you write simpler, more resilient UI components. This is Fullstack Radio episode 130. Hey, everyone. Welcome to another episode of the Full Stack Radio podcast. I'm your host, Adam Wadden. And today, it's my pleasure to be speaking with David Khorshid, otherwise known as David k Piano, otherwise known as the State Machine Guy. How's it going, man? Great. Yeah. Great to meet you, Adam. Yeah. You too. Thanks so much for coming on the show. I I read an article that you posted a couple of weeks back on, dev.2 or dev.to, I don't know how people say it out loud, called no disabling a button is not app logic and I thought it was really great because it really opened my eyes to some ways of thinking about how we can sort of implement, you know, pretty pretty common basic stuff that we do in user interfaces all the time in sort of a more resilient way using some ideas that I've I've sort of typically relegated to sort of theory, you know what I mean? And not leveraged too much in real world, applications. So I thought if it's cool with you, it'd be cool to talk about some of that stuff sort of from first principles working our way to some more advanced concepts and, you know, see what sort of interesting stuff we can cover. Yeah. Absolutely. So I think probably the best place to start would be, just with the idea of state machines in general. Like I kinda said before, to me, a state machine is like, yeah, I learned about that in university in computer science class and then kinda quickly forgot about it and just went off building, you know, real things, not thinking that that was something that I would have to use day to day. And to this day, you know, it hasn't been something that I've bumped into day to day, but reading this article and seeing some of the stuff that you talk about, it's making me realize, you know what? Like, this seems like a really powerful idea that can be leveraged in much simpler ways than maybe it sounds like at the outset. So how do you sort of like define the idea of state machines or introduce that to people usually? Well, it's funny you say that because there's been many people who have asked me, like, hey, I've learned about state machines in university. And it was usually around topics such as regular expressions or Turing machines or basically how computers and circuits work and all the things that don't really apply to what we do every day in web developments. But, if you look at state machines and you like Google them, look them up on Wikipedia, you're going to get a lot of confusing information. And they're really a lot simpler than it sounds. …

Get the full transcript (10,086 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Full Stack Radio transcripts →