[00:00.000 --> 00:15.000]  up to you. Can I start? Okay. Can you hear me? Okay. I am Gabriele Falazca, a front-end
[00:15.000 --> 00:23.080]  developer working in a company called Surzents and located in Rome. And if you don't understand,
[00:23.080 --> 00:30.160]  I will speak to you about a finite set machine with some example inspired by retro game and
[00:30.160 --> 00:42.440]  arcade games of the 90s. Let's start with this slide that is very clear and self-explanatory.
[00:42.440 --> 00:48.040]  A finite set machine is an abstract machine that can be exactly in one of finite states
[00:48.040 --> 00:53.480]  at any given time. It can change from a state to another in response to some inputs. This is
[00:53.480 --> 01:00.880]  the Wikipedia definition of finite state machine. And it's very theoretical definition. But now
[01:00.880 --> 01:12.120]  we will see how to apply that pattern in programming. For a representative finite state
[01:12.120 --> 01:20.160]  machine, you can use the state charts that are a sort of graphs where the states, the nodes are
[01:20.160 --> 01:29.920]  called the states. And the links between the nodes are called the transitions. This is the state
[01:29.920 --> 01:43.360]  charts of an application that made a fetch call. So we have the state of the application is idle,
[01:43.360 --> 01:52.000]  loading, such as, and failure. And the events that trigger the transition are fetch event that
[01:52.000 --> 01:58.840]  trigger the transition from idle to loading. Reactive event that trigger the transition from
[01:58.840 --> 02:06.400]  loading to failure. Retrievent that triggers the transition from failure to loading. And resolve
[02:06.400 --> 02:21.000]  event that trigger the transition from loading to such as. Another state chart is this, a little
[02:21.000 --> 02:30.000]  bit complex. This is an elevator. An elevator starts in idle state. When a user called the
[02:30.000 --> 02:35.960]  elevator, he passes to state prepared up or prepared down, based on the floor where is it in that
[02:35.960 --> 02:47.040]  moment. When the user select the floor, elevator passing state moving until it reaches the right
[02:47.040 --> 02:55.400]  floor. After it reaches the right floor, elevator passing in state door opening. And when the user
[02:55.400 --> 03:07.000]  left the cabin, elevator returns to idle state. Now let's create a state chart. Yes, we are going
[03:07.000 --> 03:18.120]  to create the state chart of this animation. Okay, the chart take off his panties, make military
[03:18.120 --> 03:29.320]  grids, and return to idle. So the states of the state chart are idle state. When a waiting,
[03:29.320 --> 03:42.240]  panty state, and military state. Before defining transition, I think I give you some context
[03:42.240 --> 03:48.920]  about this chart there. If you don't know, this chart there is called Yaku Taro Chimori,
[03:48.920 --> 03:57.200]  is a side chart of a famous arcade game in the 90s called Metaslag. He triggered this
[03:57.200 --> 04:05.720]  animation when the main character, Marco, worked near to him, and he made this animation for
[04:05.720 --> 04:15.880]  dropping bombs, a reward for the main character. So the first event that linked the idle state
[04:15.880 --> 04:24.640]  with the panty state is Marco is near. Second event that connect the panty state with the military
[04:24.640 --> 04:33.040]  state is a reward drop. Because after drop the reward, he redress his panties and grids Marco
[04:33.040 --> 04:43.520]  with military grids. And after, when Marco is far, he returns to idle state. Now let's see this
[04:43.520 --> 04:50.560]  event live, but before, I want to show you the simplest code of finite state machine. It's a
[04:50.560 --> 04:59.800]  JavaScript, because here we are in a room called JavaScript Debrum. But you can apply this pattern
[04:59.800 --> 05:07.440]  in every modern programming language. It's a simple ES6 class with two methods. One for setting
[05:07.440 --> 05:20.000]  a state, and the other one for executing the routine of the current state. This machine live
[05:20.000 --> 05:32.360]  we can see here. This is a little part of Metaslag game in the browser. I made for demo. When you
[05:32.360 --> 05:42.640]  press the arrow right and left, Marco walks back and forward, and when he's near Yakutaro,
[05:42.640 --> 05:54.160]  in very big screen, there are a lot of iterations. Yakutaro plays his animation, take off the
[05:54.160 --> 06:02.880]  panties and grids Marco. When Marco returns far, he returns to idle state. Let's see the code of
[06:02.880 --> 06:30.600]  this demo. We have, you see, I have to zoom. Okay. Okay, this is the HTML page. It's very simple.
[06:30.600 --> 06:42.200]  It has a sheen, that's the sheen, and two images that are the sprites of two charters. Now, we
[06:42.200 --> 06:48.240]  have a simple entry point of the application that has a demo list for the arrow keys, and
[06:48.240 --> 07:00.120]  initialize the script for Marco and Yakutaro. Our machine is the same, so in the slide.
[07:00.120 --> 07:09.560]  And the two script for Marco and Yakutaro. Marco is a simple script as just two methods for going
[07:09.560 --> 07:22.640]  back and forward. And Yakutaro script is as the finished machine as brain. So it has the three
[07:22.640 --> 07:30.680]  methods that are the states we have defined before, and another utility method for observing
[07:30.680 --> 07:42.640]  Marco and trigger the events for changing the states of the machine. And it's just this code.
[07:42.640 --> 07:59.520]  Return to slide. Another type of machine, a bit optimized from this, is the stack-based
[07:59.520 --> 08:06.800]  finite state machine. This kind of machine has not a single active state, but as a stack of state,
[08:06.800 --> 08:16.440]  and consider active the state on top of the stack. So in this model, you can navigate through the
[08:16.440 --> 08:24.800]  states back and forward way. Think the history of the browser like our finite state machine,
[08:24.800 --> 08:32.200]  where think to the web pages as the states, and the back and forward event of the browser,
[08:32.200 --> 08:41.080]  the events that trigger the transition. Okay, it's clear. This is the code of stack-based
[08:41.080 --> 08:46.600]  finite state machine. It's very similar to the previous one, but we have the stack of the states
[08:46.600 --> 08:56.040]  instead of the active state, and three utility for pushing and popping the state in the stack.
[08:56.040 --> 09:10.720]  Very simple. If you have to develop a more complex machine, there are various tools and
[09:10.720 --> 09:22.560]  frameworks. In JavaScript, the most famous is Xstate. That is a series of utility for
[09:22.560 --> 09:35.880]  finite state chart and finite state machine. This is the code of a machine created with Xstate.
[09:35.880 --> 09:46.600]  It's a very functionally way. We have got utility for creating the machine, all configuration
[09:46.600 --> 09:55.200]  based, and a toggle service for defining and sending the event, and define the transitions.
[09:55.200 --> 10:08.480]  My goal in this talk is not to show you a single framework, because you can choose one
[10:08.480 --> 10:16.680]  study by yourself. I want to explain the theory and the pattern, and how to apply it to real life.
[10:16.680 --> 10:28.000]  I introduced Xstate, because it has a cool tool called XstateVidz, that can help you to test
[10:28.000 --> 10:41.960]  your machine. The tool is this. I don't know if you see. This is the same state chart of our
[10:41.960 --> 10:50.280]  previous event, and it's interactive. You can trigger the events directly from the chart,
[10:50.280 --> 11:01.840]  and see what's happened. On the sidebar, you have three tabs. In the first one,
[11:01.840 --> 11:14.280]  you can put the code of your machine in Xstate way. The second tab is the state that contains
[11:14.280 --> 11:22.800]  all information of the current state of the machine. From the third tab, you can programmatically
[11:22.800 --> 11:51.680]  send the event for testing your machine. As you can see, I can send the event directly from here.
[11:51.680 --> 12:05.440]  You can reset the machine. My talk is finished. Have you got any questions?
[12:05.440 --> 12:23.200]  Who has the first question? And do raise the hands.
[12:23.200 --> 12:32.880]  Hello. Thank you for your presentation. What happens to your state if an event is triggered
[12:32.880 --> 12:39.800]  that you can't handle? What happens to your state if an event is triggered that you can't
[12:39.800 --> 12:50.480]  handle at that state? If they are not connected to a transition, nothing happens, because the
[12:50.480 --> 13:06.440]  machine doesn't respond to this event. This depends on the implementation that you use.
[13:06.440 --> 13:17.160]  In Xstate, the most famous implementation, this thing is safe. It depends on which machine
[13:17.160 --> 13:37.440]  you use and how you have implemented. Okay? Next question, raise your hand very high,
[13:37.440 --> 13:45.040]  please. While you think about it, thank you for the video team up there with the green
[13:45.040 --> 13:58.680]  T-shirt. They'll hear it after. Don't worry. They hear everything.
[13:58.680 --> 14:04.680]  How is the animation graphically that we see on the screen is handled with regard to the
[14:04.680 --> 14:09.840]  state machine because there is some delay. It has some time of duration. Thank you.
[14:09.840 --> 14:22.120]  The animation is how it's made. Okay. I have just the three sprites and every state of
[14:22.120 --> 14:37.560]  the machine set the correct sprite in the image tag and prepare the machine for the
[14:37.560 --> 14:53.360]  next state. Observe Marco is updated the state and run the routine of every state.
[14:53.360 --> 15:10.120]  Next question. Okay. Will you be around? Will you be around? Will you be in the deaf room
[15:10.120 --> 15:18.640]  or outside? There are no more questions. Thanks again.
[15:18.640 --> 15:24.160]  Okay. Thanks for the fish.