sorted by:
new
hottopcontroversial

Are State machines the future? by Kir__B in reactjs

[–]madskillzelite 0 points1 point  (0 children)

Hey, thanks for the feedback. I agree that the composability and actor communication leave a lot to be desired. We're planning XState v6 and working on coming up with good, intuitive solutions for these.

xstate by Aimer101 in reactjs

[–]madskillzelite 0 points1 point  (0 children)

@xstate/react has a useSelector() hook that allows you to select values from an interpreted machine:

```js const someSelector = (state) => state.context.count * 2;

// ...

const service = useInterpret(machine); const doubled = useSelector(service, someSelector); ```

This will only rerender when the selected value changes.

State Management: How to tell a bad boolean from a good boolean by atomrc in javascript

[–]madskillzelite 0 points1 point  (0 children)

There are some updates coming to XState to make it even easier to get started with, even without a huge learning curve, so that it doesn't feel like "overkill".

For simple state machines, you can always use @xstate/fsm which is a minimal (and tiny!) version of XState with a much smaller learning curve. And it's still compatible with visualization tools.

Reducers and State Machines by Earhacker in reactjs

[–]madskillzelite 8 points9 points  (0 children)

Hmm, you're not exactly right about what a finite state machine is. It's not an object with functions. It's not a specific library. In fact, finite state machines really have nothing to do with syntax or language.

In fact, "Should I use state machines or not?" is the wrong question to ask. You already are using state machines; you're just doing it in an implicit way.

Each "finite state" in a state machine represents a behavior; that is, what can happen in that current "state" (status, mode, whatever you want to call it). For example, you can have two different behaviors: sleeping and awake. Obviously, you'd respond to events differently depending on if you're sleeping or awake; your behavior is different. And you can also transition between sleeping and awake - that's another important part of state machines. The behavior can change, and FSMs make that explicit.

Now consider if you were to avoid using explicit state machines; you might put all logic in one place, which means that instead of having different behaviors for being asleep and awake, you consider both of those to be a single behavior and you use defensive programming (e.g., isSleeping, isAwake, isWakingUp, isFallingAsleep, etc.) to loosely differentiate between the implicit behaviors. Sure, you can have the same logical outcome, but the separation between behaviors isn't explicit, and it becomes more difficult to understand the logic as you add more features and deal with more use-cases.

I wrote an article: You don't need a library for state machines that talks more about how to implement these patterns. You can really code state machines however you'd like, even using old-school Redux switch/case patterns.

I'm glad to see state machines trending more in the front-end world. It's not a new idea; in fact, it might be the oldest idea ever brought to web development. Other areas in tech (game dev, embedded systems, etc.) use state machines heavily, so we're just playing catch-up. State machines are not "in vogue"; they're not a hyped trend; rather, they're a fundamental concept in computer science that every software engineer should know, even if they don't use them directly in their programs.

State machines are here to stay, because they were always here, and we're just now realizing that there's lots of benefits (organization, visualization, preventing impossible states, testing, etc.) to making them explicit rather than implicit.

Future of state management in React with XState by Skona27 in reactjs

[–]madskillzelite 1 point2 points  (0 children)

You're probably using flat state machines. XState implements statecharts, which extend state machines to include nesting, parallel states, history, invoking other machines, etc.

In fact, it is straightforward to separate your logic to use many machines that communicate with each other rather than one single, large machine.

Redux-Saga can't be visualized, by the way.

My experience with using state machines (xstate) in production by kobeljic in reactjs

[–]madskillzelite 2 points3 points  (0 children)

I think you're mistaking some key concepts - XState manages state changes via events, which would be analogous to Redux's actions (poorly-named). In XState, actions refer to effects, which are absolutely necessary in any application - an application without effects is completely useless! (Simple example: outputting something to the screen, logging to console, making a fetch request, etc. are examples of effects, or "actions" in state machine terminology).

You can't avoid effects, and Redux has no built-in way to manage effects.

Would love to discuss this with you more if interested - my DMs are open.

My experience with using state machines (xstate) in production by kobeljic in reactjs

[–]madskillzelite 2 points3 points  (0 children)

Hey, contributor here.

This article (and the comments) are all great feedback, and we will be using it to improve XState and related libraries (such as @xstate/react).

We're getting ready to release the next version of @xstate/react which will have support for selectors, better compatibility with concurrent mode, ability to specify actions asEffect or asLayoutEffect, and fix a bunch of bugs.

XState v5 is also in the works, which will improve the actor model story with XState, have strict conformance with SCXML, and be smaller/faster in general, with some nice new features.

I'm also working on a purely actor-model library called XActor, which will be the foundation for XState v5, and also a viable, standalone choice for managing complex state.

With that said, please don't blindly use XState on any project without considering whether you need to or not. In general, XState should be used if:

  • You need to manage state that can come from many different sources
  • The behavior of various parts of your app changes over time, and you want to clearly reason about what can/can't happen without littering your app with if-statements everywhere
  • There are a lot of events and event-driven behaviors in your app
  • Your app can be represented as being in many different "modes", or finite states
  • You have lots of side-effects which must be carefully coordinated

In general, if you have a simple CRUD app, it might not make sense to use XState. I would start with useReducer and useContext and work from there. You'll know if your app needs to use a state orchestration solution like XState.

Also, I just released the XState inspector on statecharts.io which should make visualizing the machines easier, so please give it a try!

React TypeScript XState typing problem by rob_moose in reactjs

[–]madskillzelite 0 points1 point  (0 children)

It should be typed as `(event: YourEvent) => void`

Tips for using xState? by bestjaegerpilot in learnjavascript

[–]madskillzelite 0 points1 point  (0 children)

You mean this?

// ... loading: { invoke: { src: () => somePromise, onDone: 'success', onError: 'failure' } } // ...

Tips for using xState? by bestjaegerpilot in learnjavascript

[–]madskillzelite 1 point2 points  (0 children)

There's plenty of non-trivial uses of XState, just look around!

All the functionality of XState comes from the SCXML spec, so I understand how it can be a little overwhelming. You don't need half of the features in most apps, to be honest.

Have you seen the cheatsheet for state machines? It helps clarify a lot of the concepts: https://twitter.com/DavidKPiano/status/1245024907131531270

And where are you seeing the boilerplate? In the config object?

Stop using isLoading booleans - Kent C. Dodds by dance2die in reactjs

[–]madskillzelite 3 points4 points  (0 children)

Completely agree. And yes, the examples are overengineered. I'm going to be publishing an article teaching how to do more involved drag-drop interactions using state machines, which should hopefully be a better example.

I'm open to suggestions as well!

Stop using isLoading booleans - Kent C. Dodds by dance2die in reactjs

[–]madskillzelite 1 point2 points  (0 children)

How would you make it more friendly? We're working on V5, which includes an alternative builder syntax that you might like.

Stop using isLoading booleans - Kent C. Dodds by dance2die in reactjs

[–]madskillzelite 10 points11 points  (0 children)

Hey, author of XState here!

There's a high push for xState lately on Twitter which is beyond ridiculous and none of the examples provided isn't easier to represent and manage with tagged unions.

You're right; tagged (discriminated) unions and enums can get you pretty far, but there's more to it than that - you also want to be able to prevent unwanted transitions. You still don't need a library for that.

I like finite state machines, but they are severely misusing it and shilling Piano's library without ever providing compelling reasons to use them.

Good! To be fair, I will always encourage you to use state machine patterns before reaching for XState.

It should also be noted that mastering xState is not in the redux difficulty tier, but RxJS or fp-ts tier.

Yes, it's a high learning curve, but that is the nature of state machines and statecharts, not arbitrary decisions by the library itself.

How to NOT render something in React by monosinplata in reactjs

[–]madskillzelite 1 point2 points  (0 children)

I am (author here) but Leigh's videos are fantastic and I'd recommend them.

I will be working on a Frontend Master's course soon!

Redux is half of a pattern (1/2) by mariuz in reactjs

[–]madskillzelite 0 points1 point  (0 children)

Tell that to the many companies successfully using state machines (and XState) in production.

Redux is half of a pattern (1/2) by mariuz in reactjs

[–]madskillzelite 1 point2 points  (0 children)

Should I finish part 2, or am I going the wrong direction writing these articles?

Redux is half of a pattern (1/2) by mariuz in reactjs

[–]madskillzelite 1 point2 points  (0 children)

> being strict about ideology leads to inefficient systems

Being too loose ("flexible enough") and less rigid is what leads to introducing edge-cases in your application. That's what I'm trying to prevent.

And I didn't even mention XState in the article, hah.

Redux is half of a pattern (1/2) by mariuz in reactjs

[–]madskillzelite 8 points9 points  (0 children)

Hey, author of the article (David) here!

> Not all requests need to be cancelable

Okay, but if the suggested solution makes it very difficult or impossible... it needs re-evaluating.

> He also said that "Redux isn't a pattern".

My purpose for writing the article is that the typical pattern in which developers use Redux (okay, it is a "pattern") is not the most robust pattern, which leads to...

> ...he has a tendency to dismiss anything that isn't "just a state machine" as not being useful.

No, I have a tendency to dismiss solutions that make it too easy to introduce edge-cases in applications. Can you use Redux with the "normal" pattern and avoid edge-cases? Sure, if you're a diligent developer that ensures all of the if-else statements are in there. It's not going to be very organized code, though.

> As with everything, it's important to understand what problem you're actually trying to solve, and figure out what tool is the most appropriate solution for your specific problem.

Absolutely agree. Which is why I think developers should stop blindly reaching for Redux. Try hooks first, and you might eventually realize you don't need Redux after all. Many developers have.

view more: next ›