Discussion on: Explain State and Props Like I'm Five

Hey there!

Props and states are driven from the philosophy that "When I make a change to a piece of code, I want that to not require changes to other pieces of code, so that I can make changes swiftly and fearlessly!"

The secret to fearless changes in software is knowing that A) you can set boundaries B) those boundaries will be respected and C) You can change those boundaries as you learn. Props and State are two useful boundaries that are provided by reactive frameworks like React and Vue.

When I think about the defining boundaries with props and state, I think about who "owns" the information.

Props are for holding bits of information or functions that other components own. The information inside of them may not be changed. "Look, but don't touch!" Think of it like letting your friend or sibling look at a picture on your phone. You wouldn't want them opening up your messages app or swiping through the photos. Whereas State is for information that the component itself owns. The information may be changed willy nilly by the component.

The next question becomes "what does ownership mean?" which, I think, is where the difficulty in delineating between props and state arises.

Let's pretend you're building a bank app. You want to add a feature that allows Person A to transfer money to Person B, so you wind up with some components:

• TransferWidget which holds the state about what accounts to transfer between and the amount
• AccountSelector which is responsible for allowing the user to select an account
• AccountDollarInput, which allows the user to input a number and validates the account balance will support it

class TransferWidget extends React.Component {
  render() {
    return (<div>Hey there! Move <AccountDollarInput account={this.state.fromAccount} /> from 
    <AccountSelector selected={this.state.fromAccount} /> to 
    <AccountSelector selected={this.state.toAccount}  />)
}

In this example, the TransferWidget owns knowing about:

• Which account money is coming from
• Which account money is going into
• How much money is being transferred.

The sub-components, AccountSelector and AccountDollarInput are given read-access to the state that they need from the TransferWidget as props so that they can use that information to make decisions. However, these sub-components cannot change that information! Agh foiled by props!

But are we?! Properties not only can provide data to a sub-component, but can also provide functions that have access to the TransferWidgets state! (see onSelected and onInput below)

class TransferWidget  extends React.Component {
  render() {
    return (<div>Hey there! Move <AccountDollarInput account={this.state.fromAccount} onInput={(amount) => this.setState({ amount })} /> from 
    <AccountSelector selected={this.state.fromAccount} onSelected={(fromAccount) => this.setState({ fromAccount })} /> to 
    <AccountSelector selected={this.state.toAccount} onSelected={(toAccount) => this.setState({ toAccount })} />)
}

These functions, when called by the AccountSelector or AccountDollarInput sub-components are used to provide information to their parent component's (TransferWidget in this case) state, which are then passed back down into the children components as properties.

But WHY?! This is complicated, passing both data and a function into a component to change that data seems like it's taking quite a few steps when one could suffice. The pragmatic answer is that the TransferWidget needs to know about the data that is selected within the AccountSelector and AccountDollarInput sub-components; without knowing about what is going on inside of the AccountSelector widget. All it knows is the agreement that underlies these components: "I give you the currently selected account, and if that changes, you tell me what the new one is."

But seriously Zee, WHY?! The more-theoretical answer comes from a few different programming concepts that take this well beyond the "ELI5" stage, but I know you can handle it:

• Separation of Concerns - (paraphrased) "My business is my business, your business is your business. You only get to do the things I allow you to with my business, and I only can do things that you allow me to with your business."
• Command Query Separation - (paraphrased) "A function that changes data must not also return data, and vice versa"
• Single Responsibility Principle - (paraphrased) "Every component/function/module has one job"

I hope this helps, even though we steered out of the ELI5 side of things!

Zee