menu

Statecharts

Statecharts are a precise way of modeling the behaviour of complex reactive systems. They describe how things work, and can help you get your code doing exactly what you want.

Channels
Team
Posts
Chat
Members
Info
Show previous messages

May 15, 2019 at 7:41am

settled will dispatch resetDisplayValue and hideResults, but only settled.itemSelected will dispatch selectItem

  • reply
  • like
7:41am

is this approach correct?

  • reply
  • like
  • reply
  • like

May 15, 2019 at 6:45pm

@mogsie, don't hardcode your brain to moore, just give it a .75 weight in case you trip and bump your head and suddenly start implementing mealy machines and need it to automatically switch for you in the future.

like-fill
1
  • reply
  • like

@hnordt It's hard for me to assess the correctness of your behaviour, but I can say that the hierarchical approach is easier to understand. It's possible to focus on inactive, and completely ignore the rest of the statechart when trying to understand inactive.

Edited
  • reply
  • like

inactive.idle seems to be unreachable, and can be dropped, while request.idle has a purpose of not debouncing until INPUT_CHANGE happens.

  • reply
  • like

It's easy to change the debouncing behaviour in active.request too. Overall, it's easier to maintain.

  • reply
  • like

@mogsie thanks! do you think I can consider actions in transitions as opposed to actions in state (entry/exit) as a code-smell if I want to follow a 100% "moore-style"?

  • reply
  • like

(it doesn't mean I'll avoid the "meanly-style" altogether, I just want to learn what is a 100% "moore-style" in the context of xstate)

  • reply
  • like

If your goal is actions in states, then yes, actions in transitions is a code smell. I'm not, however, advocating a ban on either style. The goal is not actions in states. The goal is to author understandable, maintainable statecharts. Sometimes, a transition action is just as elegant as a state with the action in it. Just like other things in programming: It depends :)

Edited
  • reply
  • like

yeah I agree

  • reply
  • like

I'm just trying to understand the difference between the styles

  • reply
  • like

I don't want to be dogmatic :P

  • reply
  • like

@mogsie I'm wondering... this code:

END_REACHED: {
target: "pending",
cond: "shouldLoadMoreResults"
}

violates the "moore-style", right?

there is a way to implement guards in xstate following the moore-style?

Edited
  • reply
  • like

hum, with null events I believe

  • reply
  • like
  • reply
  • like

typo: should be infiniteLoading only

Edited
  • reply
  • like

May 16, 2019 at 6:27pm

Just gave a talk about statecharts/xstate to a bunch of people at my company. It's missing some of the more proprietary interesting bits due to company policy, but most of it is here: https://github.com/ZempTime/StateChartsPresentation

like-fill
5
  • reply
  • like

if things keep going the way they're going...I fully expect this to spread fairly quickly

  • reply
  • like

very nice @zemptime!

  • reply
  • like

I'm doing the same, but trying to teach friends

  • reply
  • like
  • reply
  • like

That's the best part of my day.

  • reply
  • like

I'm very excited about built in support for actors in XState

  • reply
  • like

thank you very much @davidkpiano for bringing back the joy of programming to my life

  • reply
  • like