DEV Community: Chinyere Ukpong

React has Two Kinds of Data

Chinyere Ukpong — Wed, 02 Sep 2026 14:47:16 +0000

Imagine a shopping website that has a cart counter icon in the navbar, on the checkout button, and in the mini-cart dropdown. Now imagine that every time you add another item to the cart, you'd have to go update the counter manually in every single one of those places to keep them all in sync.

Luckily, this is a problem that was solved about 13 years ago by developers at Meta. They built a JavaScript framework, one that numerous platforms have since been built on top of, called React.

In React, the UI you see is simply a function of the data behind it. Whenever that data changes, the component re-renders and displays the updated UI shaped by the new data. React works with two types of data: props and state.

Props

A prop is like a topping someone else ordered for your pizza. It's data passed down from a parent component to a child. Just like the toppings, the child has no say over it; it just receives it and displays it. This is what makes props read-only, or immutable, from the child's perspective. Props aren't limited to plain data either. A prop can also be a function.

This read-only rule is what makes props useful for tracing where your UI comes from. If you want to change what's rendered, you know exactly where to look: up, at the parent that owns the data.

Here's props in action:

function Parent() {
  return <Child name="Sarah" age={10} />;
}

function Child({ name, age }) {
  return (
    <div>
      <h1>My name is {name}</h1>
      <p>I am {age} years old</p>
    </div>
  );
}

Parent owns the data and hands it down. Child receives it as props and just displays it. It never touches or changes it directly.

State

The other data type, the one that works alongside props, is state. State is data owned by a particular component: the component itself can change it, and changing it triggers a re-render so the UI reflects the new value. State comes paired with a setter function for updating it.

Here's a simple example:

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        You clicked {count} times
      </button>
    </div>
  );
}

Who decides when this value changes?
If it's a parent component, it's a prop.
If it's the component itself, it's state.

The same value can be both, depending on where you're standing

Props and state aren't two permanent categories that data gets sorted into. They're roles, and the exact same value can play a different role depending on which component you're looking at.

Take a simple name input:

function NameInput() {
  const [name, setName] = useState("");
  return <input value={name} onChange={(e) => setName(e.target.value)} />;
}

From inside NameInput, name is state. It owns it. It updates it every time someone types a character.

Now say the parent form wants to show a live preview of that name elsewhere on the page:

function Form() {
  const [name, setName] = useState("");
  return (
    <>
      <input value={name} onChange={(e) => setName(e.target.value)} />
      <Preview name={name} />
    </>
  );
}

function Preview({ name }) {
  return <p>Hello, {name}!</p>;
}

Look at Preview. That exact same value, the one that started as state inside NameInput, is now sitting inside Preview as a prop. Preview didn't create it. It can't change it. It just receives it and renders it. It has no idea that somewhere upstream, this value began life as someone's state.

Same data. Two different identities, depending entirely on which component you're standing in when you ask the question.

This is why "props and state are two kinds of data" is a slightly misleading way to think about it. The better framing: state is what you call data at the place it's owned, and props are what you call that same data everywhere it's received. A value isn't permanently one or the other. It just changes identity as it crosses a component boundary.

It's also why the test from earlier, who decides when this changes, is one you have to re-run per component, not once per value. Ask it inside NameInput, and the answer is "the input itself." Ask it inside Preview, and the answer is "whoever rendered me." Same question, same value, different answer, because the vantage point changed.

When two components need to share the same state

If state belongs to one component only, what happens when two components both need access to the same value?

Say you have the Child component from earlier, but now imagine you want a SummaryBadge next to it that also needs to show age. Your first instinct might be to let Child hold its own state:

function Child() {
  const [age, setAge] = useState(10);
  return <p>I am {age} years old</p>;
}

This works fine, right up until SummaryBadge also needs that number. And here's the problem: age is sealed inside Child. Nothing outside Child, not a sibling, not even Parent, can reach in and read it. It's a private notebook that only Child is allowed to open.

The fix isn't clever, it's just relocation: move the state to whichever component is the closest shared parent of everyone who needs it.

function Parent() {
  const [age, setAge] = useState(10);
  return (
    <>
      <Child age={age} onBirthday={() => setAge(age + 1)} />
      <SummaryBadge age={age} />
    </>
  );
}

function Child({ age, onBirthday }) {
  return <button onClick={onBirthday}>I am {age}, Happy Birthday</button>;
}

function SummaryBadge({ age }) {
  return <span>Current age: {age}</span>;
}

Now Parent owns age. It passes the value down to both Child and SummaryBadge as props, so they stay in sync automatically. Notice what it passes to Child: not the state itself, but a function, onBirthday, that calls setAge on Child's behalf. Child never touches useState. It just calls the function it was handed.

This pattern is called lifting state up, and the reasoning behind it isn't about style. It's about access. Ownership determines visibility. Whoever owns a piece of state is the only one who can read or change it directly, so the moment more than one component needs to see the same value, it has to live in whichever component is the nearest shared parent of everyone who needs it.

The rule of thumb

Whenever you're unsure what a piece of data should be, ask yourself: does this value need to be seen by more than one component?

If yes, it doesn't live where you first wrote it. It lives in their nearest shared parent.

Check out my new article about JWT!

Chinyere Ukpong — Wed, 26 Aug 2026 12:50:48 +0000

Chinyere Ukpong

Aug 26

JWTs are Like Stamped Letters

#authentication #backend #webdev

3 min read

JWTs are Like Stamped Letters

Chinyere Ukpong — Wed, 26 Aug 2026 11:17:34 +0000

My favorite thing about innovative mechanisms used in web infrastructure to deconstruct hitches is how they usually have very similar themes to our day-to-day actions.

The dilemma being solved in this scenario would be http's inability to remember anything. Much like a patient with amnesia, servers do not remember a single thing about users who have repeatedly sent a request. It would be like having to refill a hospital form every single time you visited, instead of the receptionist entering your name into the database to verify whether you had been at the hospital previously and in the case that you were found, who you are.

In a bid to eliminate this flaw, the initial remedy happened to be one synonymous to a coat rack ticketing system used in various stores where customers are usually not allowed to take in their coats with them. So the server would a generate an id for a user and store information about that user to that particular id, inherently keeping a logbook of all the users. Whenever the user wanted to perform an action, the server would look through the logbook for the user's id in order to be certain that the user could be allowed to perform certain tasks.

But of course, akin to everything in life, change is constant and more so for the purpose of efficiency and that is how json web token came about. If I were to liken JWT to something, I would say the letters in game of thrones. A JWT is called "stateless" because in contrast the logbook we spoke about earlier, It has no way of storing the details about users on the server. This is because JWT hands you a signed letter(or one with a sigil like in game of thrones) with which you bring with you. So at every stop (where you would presumably perform an action) you would show the JWT and you are would now be allowed to perform the action or not.

This proverbial letter consists of three parts namely ; the header, the payload or body and the signature. The header usually contains a title which would say "This is a json web token" (rather mundane if you ask me). The payload would contain details about the user e.g, user id, user name, user role, and so on. And finally the signature which can not be replicated without the server's secret key is made using the payload and the header.

One mistake that is often made when understanding the concept of a JWT is thinking that the payload is encrypted. In truth, the payload of a json web token is simply Base64 encoded, which means the characters are scattered around. In fact, if the JWT was intercepted anyone could decode it and see all the details about the user. It is for this very reason that we are advised to store sensitive tokens in httpOnly cookies to avoid the info being read via JavaScript in the event of an XSS attack. We are often advised to go a further step to hash the passwords stored in the database using bcrypt incase of database breaches.

JWTs are also primarily used for two reasons; authorization and authentication. Authentication is simply checking to see that you are who you claim to be as a user, while authorization is checking to see where or what you are allowed into as a user.

So in the future whenever you come across the use of JWT in your code, you can say that code imitates life, and the systems we engineer can very well be recognized in our day-to-day routines we undertake as people.