Understanding the concept of state using Pokémon and React!
Tags: react, javascript, codenewbie
Published: 2020-08-18 04:23:54

# Struggling With Defining State

As a beginner, one might find themselves trying to wrestle with understanding the concept of state- something seemingly high level, and often Google search results are linked to popular frameworks and libraries such as Angular and React, which can sometimes feel out of reach as a beginner.

State is often used to define itself through circular definitions such as: "State refers to the state of your application or component!" Super helpful, right?

Or, we get solid definitions such as those found in [Wikipedia's article on state](https://en.wikipedia.org/wiki/State_(computer_science)#:~:text=Program%20state,-Similarly%2C%20a%20computer&text=The%20contents%20of%20these%20memory,is%20called%20the%20program's%20state.&text=In%20declarative%20programming%20languages%2C%20the,changes%20to%20the%20state%20directly.): 

> In information technology and computer science, a system is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the **state** of the system.

> "Similarly, a computer program stores data in variables, which represent storage locations in the computer's memory. The contents of these memory locations, at any given point in the program's execution, is called the program's **state**."

For a super green beginner, the language may be overwhelming and a little too "techy". Stateful? Memory locations? Especially with web dev, where computer science concepts can often be glossed over in the beginning of one's learning journey, this can seem like a little too much to chew on.

The fact of the matter is, state *is* a relatively simple concept, but this simplicity may be the root of unclear explanations especially when someone experienced explains it. For those of us who are no longer green, we lose the "beginner's eyes" we used to have and often end up confusing a beginner even more with our unintentionally higher level explanations.

We will explore state in the context of a Pokémon Battle. While I will relate this example to state and give a very barebones example of how it is used in React, this article is less concerned with the best practices of React, Hooks vs no Hooks, functional vs class based components, state management, or even the code itself- we are strictly concerned with explaining the concept of state in a manner that is easily digestible.


# Pikachu, I choose you!

To set the scene of our battle: we have a `PokemonBattle` component, which is the "stage" for our actual battle. We have two `Pokemon` components, each with a specific Pokémon and its information loaded into them.

```javascript
<PokemonBattle>
    <Pokemon selection = {Pikachu}/>

    <Pokemon selection = {Squirtle}/>
</PokemonBattle>
```
Inside of our Pokémon component, we have our sprite, our health points bar, a box to hold our Poké's moves, and a box encapsulating our health points and any potential status conditions. This component may look a little something like the below:

```javascript
<Pokemon>
    <HPBox hp = {this.state.hp} status = {this.state.status}/>

    <img src = {this.props.selection.imageSrc}/>

    <MovesBox moves= {this.props.selection.moves}/>
</Pokemon>
```

Visually, this is rendered as:

![Pokemon Battle](https://i.pinimg.com/originals/f3/ca/9b/f3ca9b390cc32c7a5a34accaad1ece73.jpg)


Looks pretty familiar, right? (NOTE:I know, this is a Charmander, but hey, Google Images was doing me dirty when putting together screenshots 🤷🏾‍♀️) 


Right now, our state for each class-based component Pokémon is initialized in an object inside of our constructor like such: 

```javascript
state = {
    hp: 30,
    status: null
}
```

This object is the location where our the state of our individual components will be held. Our components will read their own `state` objects, and behave a certain way based on that state, whether this is visually or functionally. 

Remember:

> "Similarly, a computer program **stores data in variables** [...] The contents of these memory locations, at any given point in the program's execution, is called the program's **state**."

Hopefully, the above is starting to make a bit more sense! Our `state` object lives in each `Pokemon` component, and serves as the "data in variables" and "content" from the above definition. 

# Let the battle commence, and the state change!

Now, if you're familiar with Pokémon, you know that Pikachu is an Electric type. This means it has access to awesome moves like Thunder Shock, which has a high chance of paralyzing your opponent with a status condition of paralysis. 

Pikachu, use Thunder Shock! (I know, this is also not a Squirtle. It's a Wartortle though, so close enough.)

![Pikachu Using Thundershock](https://i.ytimg.com/vi/ANuOHKaYR_0/hqdefault.jpg)


We command our Pikachu to use Thunder Shock, and now our opponent is paralyzed. Previously, the Pokémon component holding our opponent had a state that included a property called `status` set to the value of `null`. When Pikachu used Thunder Shock, the code that was triggered updated the `state` of our poor Squirtle to:

```javascript
state = {
    hp: 15,
    status: 'paralysis'
}
```

Our component holding our Squirtle will re-render, and now we can see a little widget showing a paralysis status in our `HPBox` sub-component! 

![Squirtle Paralyzed](https://scalar.usc.edu/works/video-game-music-transcription/media/pokemon%20battle%201.jpg)

State is dynamic, it holds values that we expect to change. This change then affects the behavior or look of our application or components.

In the above screenshot of the paralyzed Squirtle, can see the way state has affected our component. Our Squirtle now has a visual icon reflecting the `status` affliction in our `state`, and our poor Squirtle might not be able to move! So not only has our component visually changed, but some of our functionality is now limited due to the `paralysis` value being held in the `status` property inside of our `state` object! 

Let's go back to Wikipedia's definition for a second.

> a system is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the **state** of the system.

We can liken this to our `state` object "remembering" that our Squirtle was hit with a move that ended up paralyzing it. After all, it was a *preceding event* and *user interaction* that affected our Squirtle's state in this way.

Hopefully by this point, you are now able to view state as the current condition or status of your application or component as affected by certain event in the midst of using an application, similarly to the way a Pokémon may be afflicted with a certain status condition in the midst of a battle.


# Squirtle's Revenge

Real Pokémon fans know this is a bad matchup. Squirtle is at a clear disadvantage as a Water-type versus an Electric-type. But our clever Squirtle has a trick up their sleeve: Rock Tomb, a move that doubly damages Electric-type Pokémon, just like Pikachu. Through a stroke of luck and RNG, Squirtle escapes paralysis, and the state of their component is reverted back to:

```javascript
state = {
    hp: 15,
    status: null
}
```

Squirtle may now execute the selected move, Rock Tomb.

Pikachu, however, isn't so lucky. The super-effective move has completely drained it of its health points!

![Pikachu Fainted!](https://imgur.com/pus8jrS.jpg)

Our Pikachu's state is now as follows: 

```javascript
state = {
    hp: 0,
    status: null
}
```

Based on our Pikachu's state, the player can no longer pick any moves, and at this point, our battle is over! The entire time, state has dictated the our battle, and our application at large.

# TL;DR

It may sometimes be tricky to pin down a specific definition for state, and oftentimes those who are experienced may explain state in a way that might be a little too dense for someone totally green. My aim is at this point, you can conceptualize state in the context of a Pokemon in battle! State can be viewed similarly to the condition of a Pokemon in a battle, with the current health points, status conditions, and the like being dynamic and affected by a user's input. The condition dictates what we see on our screen, and what kind of things we can do with our Pokemon.