🔴 Patreon: www.patreon.com/joyofcode 💬 Discord: joyofcode.xyz/invite

As a hobby enthusiast I often hit this wall on small projects: As the code base expands the number so too does the number of state based booleans which cause an exponential number of issues... This was super helpful!

Wait until you find out that calling methods on an object is the same as passing events. The cycle of software development probably is the endless reinvention of things that already exist but under a different name.

Among non-boolean examples XState version felt the worst. Replacing a normal code with declarative JSON-like blob of configs is a typical antipattern IMO. I also didn't get why for Reducer-based version you switched to boolean flag again. Reducer pattern can totally be used together with state enums.

State Machines are definitely very useful! I created a state machine once where each state is it's own class, and each state class has it's own events like "Enter State", "On State Ended", etc which can be overridden in child classes with functionality added about a particular state. I created a state manager system which manages the state classes as well as which state is currently active and calls the on state end, enter state functionalities. Really nice way of handling things for complex projects & also happens to be fairly modular.

I've struggled with understanding how Redux works in React for ages, it just made no sense. This video unintentionally explained the reducer pattern so well in a minute or so (and I didn't even have to slow down the video from 2x).

OOP is the exact application of what you illustrated in this video. OOP is about events and messages. The state pattern is the application of this, but better in expandability because it eschews switch cases.

Clean video, liking this format!

Great video! State machines are great for covering all possible states of a simple app: such as a video player or weighing system of cargo trucks (saw one and wrote one 🙂), but I feel like mobx class stores would be a more suitable state handling solution for an actual game

Used this video today to build a onboarding/tutorial process for my app. If I had done it with booleans I would have probably thrown it away at some point, so those tips were gold haha

This video does a great job of introducing me to new concepts. However, I found that I need to dig a bit deeper to understand **why** I might want to use a reducer over a state machine for example. I get (more or less) *how* each pattern works, but it's not at all clear *why* I would want to use each one, I don't know what its pros and cons are. A better way to go about doing this might be starting from the problem (representing state) and then working towards the solution (each different pattern). This way, the benefits of each pattern arise effortlessly from the nature of the problem and the process with which we try to solve it. The visuals are top-notch, I would recommend looking a bit more into the script and pacing of the video.

Thank you! just stumbled in exact this problem coding a simple snake game on svelte

Underrated Channel. Keep it up bro. You'll grow fast Q: how do you edit your videos with those effect?

At 1:01 I would have personally set playing = !gameOver, to prevent that impossible state, but great tutorial overall! Subbed!

If you're using a OO language (like java, Python, C#, etc) and have a lot of states, and your program will constantly be changing states, then you should just use the State design pattern. You have a parent class called State and that class has all the child states. That way all the kids can extend the parent class, implement common methods in their own ways, reduce conditionals, and it uses the open/close principle since you can add other states without messing with previous code.

I try to avoid any two States with boolean values. But I use the same boolean for different methods which will act together, like styling and form hiding.

this got from simple math to rocket science pretty quick

(NOTE: I’m on mobile so I have no idea if this will format properly) For more complicated state management I sometimes use bitmasks. Each state is represented by one specific bit (1

You're da bomb! Thanks.

I never even thought that booleans could be used to represent states if there are more than two. My default go to was just an integer but then I had to remember what each value represents, I suppose enums slove that problem.

@0:57 there are 8(eight) possible states on 3 booleans 2^3 2**3

7:37 so for each function, in this case our function returns a string describing the current state, we need to check and handle each game state? It would be easier in this case to encapsulate the functionality of each game state in a subclass, then simply rely on polymorphism. Each state state would have an associated instance, so each state change would simply return the associated instance. Super simple. To check which state were in we just check the type of the instance. This also allows us to decouple all the logic of all the states, and also decouple the state transition logic. The only drawback is not all functions exist or should be implemented for each state. Eg no point in being able to pick a card when the game is over. But this says more about the design than the state machine pattern. It would indicate the state machine is encompassing too much. Perhaps a separate state machine is needed for a running game. But that's another discussion al together.

Didn’t know you can declare variables inside the markup like that. Always a feature I wished svelte had. I just didn’t know lol

Very well done!

Great content! 👏

I miss my "Hey friends" :) Thanks for the vids.

The video quality is absolutely awesome. Is there a tool that you use? Fantastic content.

Big fan of function pointers/delegates for state based interactions - removes most of the if's associated with state management Not sure if Javascript has those though, I do C# and am trying to pick C++ up again

Great video! I agree that booleans shouldn't be overused for representating states. I always prefer enums/reducer. The problem with enums is language support. TypeScript lacks expression-based if & switch control structure and type constructors, which makes working a bit boilerplate-y and verbose

1:16 1:52 first time -seeing- noticing font ligatures enabled in a video... which application are u using to show this code?

Is it faster to execute?

What is your views on using reactive statements? mainly in regards to performance , do you think it hinders it vs just calling a function at a time you want to check something like if matches is = to emojis etc . I get nervous using reactive statements as it seems like magic , not sure if there is a negative side to too many reactive statements

I do not see the point of the XState configuration using string names to index callbacks that could have just been passed as function pointers -- they are already effectively doing that with the "actions" object literal. Is this some specific issue with JavaScript garbage collection or is it a quirk of the library? (Genuinely curious about this. I've spent the past several years getting intimately familiar with Python and some mathematical stuff, and very recently learned Go, but I haven't been keeping up with EcmaScript for a few years.)

I was following until I got to the state machine part things got too abstract, but the explanation is very good, thanks.

Why not use an integer as a state system? 1 is menu, 2 is playing, 3 is paused, 4 is game over. The code for the menu and game over states wipes data from the playing state, while the pause state retains it. The pause and playing states have bindings to the pause key to call each other, but the binding doesn't exist outside of that, so there is no need to check for an invalid state in the menu and game over codes. There are no impossible state setups here, you don't have to do defensive programming, and you avoid unnecessarily complicated state machines where they're not needed.

Awesome video! What theme do u use?

I definitely should revisit my code for image processing Telegram Bot using a state machine and draw a proper diagram (even though existing code works well enough)

please is there a blog or an article i can go read about this more

No, please don't. I'll be the first one to say I enjoy your channel, but please for the love of god don't promote state machine in Svelte. I understand this is not a Svelte tutorial, but at least explain the cons of state machines in general as well. The reality is that in a real world application nobody will bother to put the whole state in 1 single file much less type the state using string literals as types. This system quickly devolves into actions management, selectors and reducers, for the low low cost of useless mind fuck abstractions. It's a non zero cost abstraction that looks nice on paper which was meant to solve a series of problems in a declarative way for context free grammars. At least that's how they will introduce it to you in school or university. Yes it's useful in general. Yes there are better alternatives to state management. Which brings me back to Svelte. Reactive statements are already solving the state problem in a much better way. And there are some clever ways of using them without losing readability at all. If you really want to express your state in a more declarative way use derived stores or plain inline named functions invocations in reactive statements, instead of nesting your conditionals inside your reactive statements. And there are even more cons to state machines in UIs. It even encourages code duplication: Say for example you've been hired to build an application for a company. 6 months into the project you're being told the application will go open source but parts of it will remain proprietary, so you have to make an open source library and use it in the proprietary application. Guess what? Some of the proprietary state for some features will have not just extra things, some times the state will work differently, meaning a state refactory. What would logically need to be a feature enhancement will turn into a whole new component. If you're thinking about using this approach in your work application, do yourself a favor and build an Angular application with ngrx, throw in 50-ish containers/components and then admire the useless complexity. If you use state machines you will have many regrets, coming from someone using them everyday without the luxury of ditching them.

How do you get === and => to look like they do? That's a nice touch.

I dont know if you are the same who writes in the website. But I love it. For this case: I really hate react, and thats why I switched to svelte. So I feel like going back to the ugly redux days. For me is a no-go

love your videos man! are you going to do a pocketbase auth crud app tutorial anytime?

Nice video, thanks. State machines are awesome, I know about them for a long time but didn't use them yet. I've learnt about them when I looked at how to program regex engine. Maybe in game project I plan to do .. PS: 6:26 ... 🤣🤣🤣

7:40 where the hell do matches and emoji come from? Am I just stupid and missing something obvious? Or was it just pseudocode that I inspected too closely?

i love your videos, thank you! :)

I often start out with an enum for State. Then realise some states aren't exclusive: if gameover plays a cutscene the user should also be able to pause. So end up doing a pause bool

Why would I make a boolean "isPlaying" and use that to check instead of checking the Enum directly? Is there any obvious advantage that I overlook?

I totally agree with using state machines, but I personally don't like the way x-state works, and as you said, it's just an example of how it can be done, I would recommend the usage of the design pattern State and its variants, are so useful and don't need any library

1/3: Hey there! 👋 I just watched the course you mentioned, and I must say it was 🔥! The hands-on approach really made a difference. I've seen a few other courses too, but yours definitely stands out. I'd give it a solid 10/10. 😄 2/3: By the way, I checked out your website and your other works, and I have to say, you're quite the artist! 🎨👌 I have a suggestion for your next video: How about creating a video on designing a system using Svelte? 🎥✨ It would be awesome if you could dive into the key elements of building a top-notch design system. 💪 3/3: And to wrap it up, it would be fantastic if you could even compare different design systems or component libraries towards the end of the video. 🔄🔍 I think it would provide great insights for designers and developers alike. Looking forward to more amazing content from you! 🙌😊 ❤❤

Nice.

In short video about svelte useReducer or redux patatern was better than svelte useState, by author opinion

Solution how this should be implemented from the start is in here - 2:48

Typescript enums have a sluw of issues, I would strongly recommend avoiding them and just use objects with "as const" at the end if in typescript

🎯 Key Takeaways for quick navigation: 00:00 🚀 Introduction to State Management Issues - Introduction to the complexities of managing state in user interfaces, focusing on the problem of using booleans. - The example of a game is given, highlighting hidden complexities that could also apply to other UI elements like multi-step forms. 00:30 ❗ The Problem with Booleans - Explains the limitations of using booleans for state management, including how they can lead to impossible states. - Demonstrates a Svelte example using booleans to manage game states, showing the issues that can arise. 02:19 🎯 Good vs Bad Booleans - Differentiates between good and bad booleans, stating that good booleans are derived from state. - Provides examples where booleans might still be useful. 02:35 🔠 Enumerated Values to the Rescue - Introduces the concept of enumerated values (enums) for more explicit state management. - Shows how to replace booleans with enums in TypeScript, reducing errors and making the code less prone to impossible states. 03:49 🤖 State Machines as a Solution - Discusses the advantages of state machines in modeling complex state transitions. - Utilizes stately's visual editor to demonstrate a card game as a state machine. 05:27 💡 Implementing Reducers in Svelte - Describes how to implement a reducer pattern in Svelte, comparing it to state machines. - Provides code examples to create a custom `useReducer` hook in Svelte. 06:37 🛠 DIY Simple State Machine - Walks through creating a simple, event-driven state machine using Svelte. - Demonstrates how this approach eliminates the need for defensive programming. 08:56 🎛 Exploring XState -Discusses when to use and when not to use XState, a state machine library. - Demonstrates how to set up a state machine using XState, detailing actions, guards, and transitions. 11:32 🌟 Benefits and Conclusion - Summarizes the benefits of using state machines and enumerated values over booleans for state management. - Encourages the audience to avoid using booleans for representing complex state in their applications. 12:01 🎵 Outro - Thanks the viewers and invites them to like, subscribe, and join the Discord server. Made with HARPA AI

Wow ! 👍👍

State Machines are not the holy grail of state management. I my experience, they work great when you have complete control over the business rules around how the object can switch between states. But as soon as you hit the real world, it often happen that new states keep popping up or the business rules surrounding the associated events change/complexify to the point where you have to by pass the validation/events completely. This is why I am now using enums in most cases and move the validation/state switching into a service object.

I usually never comment or like videos. But this was very well done.

I don't understand what a reducer adds when you already have a store. Granted i don't understand reducers at all, every time I've looked at them for state management they just seem like a great way to obfuscate control flow and add tons of boilerplate. The reason svelte is awesome is because all of that noise isn't really needed.

the diagram thing reminded me of "goto"

just use bytes, it is more resource efficient: 0: Game Over 1: Playing 2: Paused

Any new drops ☔❤

The cheapest aspect of modern computers is memory. Using enumerated States is MUCH faster to execute even if it requires duplicated code. Moreover most compilers (although not Javascript) permit you to write the code once as a function, and then the compiler will replace all calls to that function with the code itself when you tell the compiler to optimize for time at the cost of increased storage. This also makes the code easier to design, debug and maintain.

Remember strings are expensive

A tutorial about how to turn a simple and readable code in a hell to refactor, and something that is against the Svelte philosophy.

types as state *mind blown*

On top of booleans being bad for the developer if you have tons of them, they are also bad for the computer. Every boolean in every major programming language takes up a whole byte for a simple true/false value. A byte should be able to hold 8 of these. On the other hand, using enums like bit flags enables you to do just that. Not only that, you can also set them up to manage mutually exclusive states by using more bits for certain enum values. A C# example might look like: public enum foo : byte { NONE_STATE = 0, BOOL_STATE_0 = 1, BOOL_STATE_1 = 2, BOOL_STATE_2 = 4, BOOL_STATE_3 = 8, EXCLUSIVE_STATE_0 = 16, EXCLUSIVE_STATE_1 = 32, EXCLUSIVE_STATE_2 = 48, ... } It is amazing how much information you can stuff into a byte if you just try.

aren't there 8 states (2³)?

There's an even worse way to manage states, using bit masks and bit flags. For example, the number 2 in binary is 10 and so you can use (value & 0x02)

I feel like this video implies that games are made in rust lol

the truth of the matter is "it depends on the project"

As a Rust dev I can stick with enums :)

State machines are great. “let” is a footgun.

Ah yes edit events is always the final frontier.

Mas que feira

Ngl, the functional paradigm feels like a bastardization of JavaScript -- JS was not designed to be a functional language -- it was barely designed at all, but the design work that did go into it made it object-oriented. The big thing back in the day was to use the prototype system to build systems of inheritance using the "function" keyword as a stand-in for "class" because whether a function call was a function call or an object instantiation was determined by the respective lack or presence of the "new" keyword. This modern JS code looks like a different language entirely at times, with very unclear relationships between things sometimes -- you just need a mental map to follow invisible lines that are often visible in other languages/paradigms -- it's very difficult to reason about a modern piece of JS code without finding some relevant documentation somewhere.

If you didn't know anything in this video , you should go back to school immediately, and I better not find your code outthere in production! Really guys, this is not just basics, it is basics of basics. Anything more complex than hello world is one way or another uses state machine.. and if you have 2 bools, 95% chance you will be better replacing them with enum, for 3 or more bools- 100% replace them!

Clicked out of curiosity because I NEVER saw someone using booleans to control state machines (of course, with more than 2 states) But ended up not watching the entire video due to a silly mistake at the start that made me lose the interest: 3 boolean variables don't give you 6 possibilities, but 8 Not complaining, just pointing out that things like that make people drop out

forget states and shi* man, svelte is sexy.

you tracking my activities? huh?

no 👍

xstate gets hairy VERY quickly when you need to do more complex things.

Blindly replacing boolean with string enum is a bad advice. Do whatever looks good for your code because whatever optimization you do, javascript still a high-level language. You want more optimization? Do that in Rust, or even better with non-plusplus C, or perhaps assembly if u dare enough.

Your game machine has a lot of unhandled cases

why am I getting svelte content? smh loo

you could have used a good language

Xstate code is plain ugly.

Insert 'Jump on Rake Meme' template, stop it, get some help.

json programming. Tom is a GENIUS