DEV Community

Discussion on: State Driven Development for User Interfaces (Part 2: Finite State Machines)

Collapse
 
dallgoot profile image
dallgoot

yes, thanks i guess that in this situation "LOCKED" is a shortcut for "CLOSED & LOCKED"

What i was thinking out loud with that question was about the intricacy of composite states as you call them and if any guidance is known to deal with them, theorytically and codewise :)

Not to push you to have an answer, just if there's some reflections on how to process : setting a hierarchy of states, linking them, etc
Some methods to approach it smartly like you did :)

i assumed that enters the realm of FSM but correct me if i'm wrong ;)

Thread Thread
 
nimmo profile image
Nimmo

Now that you mention it, perhaps my example is actually just too simple to address your question properly - my apologies, let's have a look at this in a little more depth. :)

In the third part of this series (which I realise you've already read), I talk about parallel state machines. That hinted at hierarchy but didn't explicitly discuss it, perhaps I should extend that post to include a better example. But did you notice how in that post, we moved from the concept of a door as a container, to a room instead, which contained a door and an alarm? This is showing a hierarchy like the one you're asking about (although again in a more simple manner really). Extrapolate this to to be say, a house that has multiple rooms each with their own doors, and you have parallelism and hierarchy being dealt with at the same time, but where each room is independent of one another, whilst the whole system is still only able to be in one state (made up of the combination of the states of all the rooms) at any given point.

In terms of implementing these in code, my take on this so far with React has been that each container is itself a representation of a finite state machine. The outermost App being the entire thing, and every container below that being an FSM that either has "sub" FSMs or parallel FSMs. If you match that to the diagram in part 3, which shows the room, then the room is a container in React that contains both the door and the alarm. Diagram and code for reference. :)

The key thing to think about here is that even just by asking the question, you're thinking about planning the architecture of your application at the right time - i.e. before you've started writing it! :) Changing your mind on how a system is put together is a lot easier when it's still just a diagram isn't it. :D

Thread Thread
 
dallgoot profile image
dallgoot

I agree : thinking in terms of FSM it 's an approach that's not only easier but more related to reality of systems, if i could say so.

From your answer i understand that, in fine, a FSM can also be looked as a group of states which implies that the "root" state are defined by the states of its "children" without having to care -i assume- about all the possible states of the entire application.

thank you for these articles and answers :)

Thread Thread
 
nimmo profile image
Nimmo

You're welcome, thank you for reading them! :-)

And yes, that's exactly it. Basically this whole thought process isn't really about building applications with FSMs, it's about recognising that your system is an FSM already (even before you've built it!) and using that realisation to allow you to better plan out your application from the start.