Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
1×
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.

Autoplay

    Trigger Actions When Entering and Exiting a XState State

    xstateXState
    >=4.6.7
    javascriptJavaScript

    Actions aren't limited to being called on transitions. They can also be called when we enter or exit a state node. This is done through the entry and exit properties.

    The API for entry and exit actions is the same as that for actions on transitions. It can receive a single function or an array of functions, each which will be called with the next context and the event object that caused the transition.

    This is a powerful way to fire side effects based on states rather than transitions.

    javascript//...
    states: {
      broken: {
        entry: [
          (context, event) => {
            sideEffectToFireWhenWeEnterTheBrokenState(context, event)
          }
        ],
        exit: [
          (context, event) => {
            sideEffectToFireWhenWeExitTheBrokenState(context, event)
          }
        ]
      }
    }
    Code

    Code

    Become a Member to view code

    You must be a Pro Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    orLog In
    Discuss

    Discuss

    Transcript

    Transcript

    Instructor: Here, I have a light bulb machine that has actions being called on the break events in the lit and unlit states. This action tells us that the light bulb has broke, and if a location has been added to the event object, it'll tell us what location it is in.

    However, adding these on both break transitions is a little tedious and unnecessary. What if, instead of calling this action on a transition, we could call it when we entered a state as well? Well, we can by using the entry property.

    Entry is exactly like actions. It can take a single function that receives the context and an event object. It can also be an array of functions, and it can be an array of strings. In our case, we can move this log broken action that's been defined on the second argument to machine, the options object. We can add that as an entry action on the broken state.

    I can then undo this work on both breaks using the shorthand of broken and update my machine. We now see that, whenever the broken state is entered, the log broken action will be taken. We can do this by going to the events panel.

    We can select break, and we can add the location in. We send that to our machine. We see we've entered the broken state, and if I open my console, we'll so, "Yo, I am broke in the office." Now, it makes sense that, if we can call actions when we enter a state, we should also be able to call actions when we leave a state.

    Those are called exit actions and are added on the exit property. Perhaps when I exit the lit state, I'll say something about it growing dark and cold, a morbid little light bulb, wouldn't you say? We've updated our machine, and we now see that we have an exit action on the lit state.

    If I toggle to lit, and then I open up my console, we can see that when we exit the lit state, "It is so dark and so cold." It doesn't matter whether we exit it to go to unlit or that we go to break. What happens when we call exit transition actions and entry actions all in sequence? What order do they go in?

    Let's add an action on the break event from lit and see what order they all fire in. Now, we'll toggle into our lit state, and we can see that we have exit actions, we have transition actions, and we have entry actions on broken.

    When we call the break event, we see that the exit action of our current state, lit, was called before the transition actions of break, which was called before the entry actions of broken. This is always the order of actions fired.