I'm confused. What is this Brian Boyko guy talking about?

[covert estuary]

😕 https://www.reddit.com/r/reactjs/comments/ilfi4c/my_experience_with_using_state_machines_xstate_in/

[covert estuary]

Sorry, I'll be more specific. Is this a true statement?

"XState operates almost entirely with side effects and as a result, when bugs appear, they are very difficult to track down. What the XState team cites as design goals, I consider direct antipatterns. For example, XState encourages the use of side effects, and encouraging the use of side-effects in and of itself is an anti-pattern. If you're putting side-effects into your actions - synchronous or asynchronous - you are doing state management wrong."
.

What about this?

"XState encourages the use of an Actor-model-like approach, where there can be many hierarchical statechart/"service" instances that communicate with each other—a hierarchical collection of tightly-coupled, loosely cohesive states that are very easy to turn into spaghetti because of their intercommunication and hierarchical nature."

[covert estuary]

Any insight on this exchange? Does this guy know what he's talking about? I'm confused about the

"xstate encourages side-effects"

statement. Does it? Where? In event handlers or functions?

Isn't XState supposed to centralize your app's logic and help reduce spaghetti code?

*"a hierarchical collection of tightly-coupled, loosely cohesive states that are very easy to turn into spaghetti because of their intercommunication and hierarchical nature." *

[delicate pond]

I wouldn't read too much into that critique. It seems he's confusing side-effects (effects that happen "on the side" and often aren't intentional, like what can happen when you take your medicine) and effects (the stuff in your app that actually does something: updating state, rendering to screen, fetching stuff from the server). The former can be bad, but the latter is completely essential if your app does anything meaningful at all.

XState (or statecharts, really) promotes the notion that state and effects are two sides of the same coin, and that they should be managed together

[covert estuary]

huh?

From React's Docs:
"While functional programming relies heavily on purity, at some point, somewhere, something has to change. That’s kind of the point of programming! These changes—updating the screen, starting an animation, changing the data—are called side effects. They’re things that happen “on the side”, not during rendering."

"In React, side effects usually belong inside event handlers. Event handlers are functions that React runs when you perform some action—for example, when you click a button. Even though event handlers are defined inside your component, they don’t run during rendering! So event handlers don’t need to be pure."
https://react.dev/learn/keeping-components-pure

[full pilot]

I replied to Brian here: https://medium.com/@DavidKPiano/there-are-so-many-fundamental-misunderstandings-about-xstate-and-state-machines-in-general-in-13aec57d2f85

This is a blast from the past 😅

[covert estuary]

Reading now. Thank you.

[covert estuary]

Why don't you post this article on the reddit thread?

[full pilot]

Because it's 3 years old 😛

[covert estuary]

It's still the top search result for "XState vs Redux". I imagine a lot of people read that and never give XState a chance.

[full pilot]

Really good call. Maybe we should post a blog post about it

[covert estuary]

Actually it's the second result (article), your response is the first. I think I saw that yesterday but ignored it because it was written by you and I wanted to get an unbiased opinion. I didn't realize that it was a response to Brian's post.

So that's why you should post it on the thread. For idiots like me.

😁

I imagine it still gets read by a lot of people though. So it should at least be tagged a misinformation.

[hoary seal]

That’s a long phone you got there.

I don’t have any problems debugging so far. For me xstate is just a way of organizing code, in a way that can be directly mapped to business requirements.

[full pilot]

Exactly!

[covert estuary]

That's not my phone. It's a chrome extension on my mac. https://chrome.google.com/webstore/detail/gofullpage-full-page-scre/fdpohaocaechififmbbbbbknoalclacl?hl=en

[covert estuary]

I'm assuming your responding to this:
"XState operates almost entirely with side effects and as a result, when bugs appear, they are very difficult to track down."

[covert estuary]

Your article responding to Brian addresses this statement:
"XState operates almost entirely with side effects and as a result, when bugs appear, they are very difficult to track down. What the XState team cites as design goals, I consider direct antipatterns. For example, XState encourages the use of side effects, and encouraging the use of side-effects in and of itself is an anti-pattern. If you're putting side-effects into your actions - synchronous or asynchronous - you are doing state management wrong."

What about this "spaghetti code" statement:
"XState encourages the use of an Actor-model-like approach, where there can be many hierarchical statechart/"service" instances that communicate with each other—a hierarchical collection of tightly-coupled, loosely cohesive states that are very easy to turn into spaghetti because of their intercommunication and hierarchical nature."

Doesn't XState prevent spaghetti code by centralizing the logic?

[full pilot]

Yes it does; I don't understand the spaghetti code statement because 1) it's highly dependent on how you model the actor system and 2) XState provides ways to organizing, whereas non-actor-model-based state management lacks anything for organization altogether

With 1), sure it's easy to make spaghetti architectures, but the same can be said for microservices, monoliths, etc.

[covert estuary]

He's not comparing XState to microservices or monoliths. He's comparing it to Redux. Having said that, I'm not familiar with microservices or monoliths. I'm curious though, does the Redux pattern prevent making spaghetti architectures somehow?

[full pilot]

It forces everything into a single, global "store" which makes communicating with external stores implicit

[covert estuary]

Is there someone less important than you that can answer my questions? I know for a fact you have more important things to do that than respond to every one of my brain farts...

[full pilot]

Hah I'm not more important than anyone else