Skip to content
wannacode

Lifting state up

In short: Lifting state up moves shared state to the closest common parent: data come down as props, and changes go up as an event (emit).

Problem

The badge at the top does not know

The shop has a cart badge at the top and a list of products below. Add bread, milk and one more bread.

Vue

The bread card says "In the cart: 2", and the top says "Cart (0)". The cart lives in ProductList: that is where the button is pressed and where the state was added. CartBadge is another component, a sibling of ProductList, and it has its own number that nobody changes. The two components have two carts, and each is right about its own.

The idea

Up to the common parent

A component sees only its own state and the props its parent passes to it. A sibling cannot see its sibling. So two places that show one cart cannot each have their own.

The solution is to move the state to the closest common parent of the two. Here that is App. This is called lifting state up:

  1. App keeps items and computes count.
  2. Data come down as props: count to CartBadge, items to ProductList.
  3. Changes go up as a message: the button in ProductCard does not change the cart, it tells App "add this product".
<script setup>
const items = ref([]);
const count = computed(() => items.value.reduce((sum, i) => sum + i.qty, 0));
function add(product) { /* changes items */ }
</script>


<template>
  <header><CartBadge :count="count" /></header>
  <main><ProductList :products="PRODUCTS" :items="items" @add="add" /></main>
</template>

The child declares which events it sends with defineEmits(['add']) and sends them with emit('add', product). The parent listens with @add="add", the same way it listens to @click on a button.

Now CartBadge and ProductList have no state of their own for the cart. They show what App gives them.

See it

See it move up

At first the cart is in ProductList. Then it moves to App and flows down from there.

App.vue
<script setup>
const items = ref([]);
const count = computed(() =>
  items.value.reduce((s, i) => s + i.qty, 0),
);
function add(product) {
  plusOne(items.value, product);
}
</script>
<template>
  <CartBadge :count="count" />
  <ProductList :items="items" @add="add" />
</template>


<!-- ProductList.vue -->
<ProductCard v-for="p in PRODUCTS" :key="p.id" :product="p"
  :qty="qtyOf(items, p)" @add="(product) => emit('add', product)" />


<!-- ProductCard.vue -->
<button @click="emit('add', product)">…</button>
Step by step, in words
  1. CartBadge and ProductList are siblings: both are children of App. At first the cart lives in ProductList, and CartBadge has its own count.
  2. A click on "Add" reaches ProductList, and the list counts 1. CartBadge cannot see that state: a sibling cannot read another sibling. It stays at 0.
  3. The fix: move the cart to the closest common parent of the two, App. The badge drops its own copy.
  4. From App the data flow down as props: count to CartBadge, items to ProductList and qty to every ProductCard. Both siblings now read one cart.
  5. The child does not own the cart, so it cannot change it. The click emits the event add with the product. ProductList passes it on, and App listens with @add and calls add().
  6. App changes items, and the new props flow down: the badge says 2, the card says 2. Nobody updated them by hand.
  7. The rule: the state lives in one place, as high as needed and no higher. Data go down as props, changes go up as events.

The direction is the same in every app: data down, messages up. Whoever owns the data is the only one who changes them.

Try it

Move the cart up

The cart is in ProductList, and CartBadge counts a number of its own. Move the cart to App: CartBadge gets the count as a prop, ProductList gets items and reports "Add" up. The check adds bread, milk and bread and looks at the cards and the badge.

Vue

The idea

The child reports, the parent decides

ProductCard does not know how the cart is built. It only knows that someone pressed "Add" on its product. So it reports what happened, not what to change: "add this product", not "increase qty on line 2". App decides what that means: a new line or one more unit.

This keeps the card simpler, and it can sit anywhere: in the catalogue, in "Recommended", in the search. It does not own the data and does not touch them.

The event is a verb without on: add, remove, change. The child declares it in defineEmits(['add']), sends it with emit('add', product), and the parent listens with @add. The second argument of emit is what the parent's function receives.

Try it

Fill in

What goes in the blank so that the click reaches the parent?

<script setup>
defineProps(['product']);
const emit = defineEmits(['add']);
</script>

<template>
  <button @click="('add', product)">Add</button>
</template>

Try it

Find the bug

A click on "Add" does nothing, and the console is empty. Which line is to blame?

Pick the line with the bug.

The idea

When the tree gets deep

How far up? As high as needed, and no higher. If only ProductCard uses something (whether the description is open), it stays in it. You move it up when a second component has to see it.

In a real shop the cart is needed in many places: the badge at the top, the list, the product page, the order. The common parent is high up, and the way to them passes through components that do not use the cart, they only pass it down. This is called prop drilling. With two levels it is normal. With five levels every component on the way has to know about data that are not its own.

There are separate tools for this: provide/inject and Pinia. They give the data to distant descendants without the components on the way. They are in the lesson on shared state in the module "Effects, data and forms". The rule stays the same: the data have one owner, and changes go through it.

More precisely, if you are curious

Props are read-only. props.qty = 3 in Vue changes nothing and writes [Vue warn] Set operation on key "qty" failed: target is readonly to the console. A child that wants a change reports up.

v-model on a component is the same thing. <QtyInput v-model="qty" /> is short for :modelValue="qty" and @update:modelValue="(v) => qty = v". The data still come down as a prop and still go up as an event.

Why defineEmits. Declared events are documentation: you see what the component says. And Vue checks them: if the card sends emit('added') and has declared only add, the console says Component emitted event "added" but it is neither declared in the emits option….

A copy is not lifting. ref(props.items) in the child does not copy the array: it is the same reactive array of the parent, and whatever is added shows up. But items.value = items.value.filter(…) changes only the child's box. The removal never reaches the parent, and the two carts drift apart.

Exercise

The cart on the side

Next to the list there is a third part, CartSummary: the heading "The cart", lines like "White bread × 2" with a "Remove" button, "Total: €4.00" and "The cart is empty" when it is empty. Right now CartSummary keeps a cart of its own that nobody fills. Give it the cart from App and make "Remove" remove from it. The check adds three products, removes them and looks at the badge, the cards and the total.

Vue

Test

Check yourself

1. CartBadge is in the header, ProductList is in the main part. Both are children of App. Where should the cart be?
2. ProductCard does emit('add', product), and App writes <ProductList :items="items" /> without @add. What happens?
3. Why does ProductCard not change the cart itself, but report up?
4. The cart is needed by a component five levels below App. The three components on the way only pass it down. What is this called?

Made by Ivo Gergov as part of Evo Tech's campaign for accessible programming education ·