State, Props, and Stranger Things

State and Props. Two things crucial to understanding how we build components in React, and yet, while easy enough to regurgitate a definition… it become a bit more difficult to explain in one’s own words. Huge thanks to Flatiron instructor Derek Cerretani who helped me get to a point where I was able to believe that I knew what I was talking about.

What follows is my attempt to explain state and props… in mostly plain English. Any errors are my own, though hopefully only typos. Also, for the purpose of this article, I’m going to say PROPERTIES (as opposed to props) because those two extra syllables do much to reduce the cognitive load that comes from the word “props” commonly associated with phrases like “MAD PROPS ON THAT AWESOME KICK FLIP!” or “Where’s the decapitated head prop for the scene with the monster” and likewise “Can we get an intern to replace the props guy?” …

In short: props sound like physical objects (all the more confusing when thinking about Object Oriented Programming) whereas there is no confusion about the “properties” of an object.

So. Where does the Netflix TV series Stranger Things fit in to all of this? Think of Season 3, with the Mind Flayer. Even if you haven’t seen it, the analogy should still hold. The Mind Flayer is an evil monster from the upside down world that makes puppets out of people. To put it simply: The Mind Flayer represents STATE. And all the potential puppet people are stateless components until they get possessed by the Mind Flayer, who alters their properties.

To rephrase and reframe in a more “codery way”, “state” is typically what you get back from a database. It’s what goes into the container that all other aspects of the app draw upon.

Speaking practically, if your database is hit, you probably want to involve State. But REMEMBER: this may also include input that a user enters LIVE, (especially if it will have an impact on the user experience over the course of an app).

Stateless components could be: buttons, “adlib inputs”, fields that get rendered automatically like date and time… or anything that might make use of data summoned up by the container.

The relationship between State/Stateless Components and their Properties, if expressed as a venn diagram might be: container components have state and include stateless components, not the other way around.

However, there will also be situations where properties do not make use of state (the color, shape and size of a button you generate would be a stateless component). Also, there will be also be things that have state, that don’t have properties. Going back to Stranger Things: the Mind Flayer has and maintains state, regardless of the person components that it uses to interact with our world. In other words, The Mind Flayer exists even if doesn’t have any Billies or rats to possess. It just goes on being evil and waiting for some person (or rat) component, some “Billy”, to come along and get possessed.

As a rule of thumb: we avoid updating state across many components because its powerful and could cause lots of conflicts. Imagine if Mind Flayer had a ‘significant other’ and It also wanted to control people? What a mess. So, like the wise writers on Stranger Things that put Mind Flayer at the top of the bad guy food chain, we would do well to manage state as a hierarchy in the context of The Largest Container Component, down to the smallest container component (though when it comes to “containers” less is obviously more).

If you’ve made it this far, you may be wondering: where do we coders usually screw up state vs stateless components? The short answer is: stateless components ought to be REUSABLE. And when we say “reusable” you could read it as “flexible”. An important thing to walk away with from this post is: State has form, something Stateless doesn’t. Something that is “stateless” is necessarily “flexible” or “reusable”.

To take it a step further: it’s easier to refactor and reuse components that don’t have state. A button for example that has “state” would be a unique snowflake, ((and not very practical for mass producing many other buttons)). So, we ought to leave state for the important things that NEED to be unique, not those that will be used everywhere else to assemble our web app.

To restate with a final concrete example: your container component summons all the data you need to manage the state of the app. Your stateless components (with the help of their properties) are used to manipulate that data in many different ways.