You now have an add-movie form, a movie list and filter buttons. Each works alone. Put them on one screen and they don’t talk to each other: the form can’t add to a list that lives in another component, and the list doesn’t know which filter button is pressed. Components can’t reach into each other’s state. That’s deliberate, and the fix is a pattern you’ll use in every React app you build.
\nHere’s the filter bar as you might first write it:
\nfunction FilterBar() {\n const [filter, setFilter] = useState('all');\n return (\n <div>\n <button aria-pressed={filter === 'all'} onClick={() => setFilter('all')}>All</button>\n <button aria-pressed={filter === 'to-watch'} onClick={() => setFilter('to-watch')}>To watch</button>\n <button aria-pressed={filter === 'watched'} onClick={() => setFilter('watched')}>Watched</button>\n </div>\n );\n}The buttons highlight correctly, but MovieList is a sibling. It has no access to filter, so it shows everything no matter what you click. State is private to the component that declares it.
Find the closest component that’s a parent of everything that needs the state. For the filter, that’s App, the parent of both FilterBar and MovieList. Move the state there, then:
export default function App() {\n const [movies, setMovies] = useState(INITIAL_MOVIES);\n const [filter, setFilter] = useState('all');\n\n const visible = movies.filter((m) =>\n filter === 'all' ? true : filter === 'watched' ? m.watched : !m.watched,\n );\n\n function handleAdd(title) {\n setMovies([...movies, { id: crypto.randomUUID(), title, watched: false }]);\n }\n\n return (\n <main>\n <Header movies={movies} />\n <AddMovieForm onAdd={handleAdd} />\n <FilterBar value={filter} onChange={setFilter} />\n <MovieList movies={visible} />\n </main>\n );\n}\n\nfunction FilterBar({ value, onChange }) {\n return (\n <div role=\"group\" aria-label=\"Filter movies\">\n <button aria-pressed={value === 'all'} onClick={() => onChange('all')}>All</button>\n <button aria-pressed={value === 'to-watch'} onClick={() => onChange('to-watch')}>To watch</button>\n <button aria-pressed={value === 'watched'} onClick={() => onChange('watched')}>Watched</button>\n </div>\n );\n}FilterBar no longer has state. It displays value and reports clicks through onChange. A component like this is called controlled: its parent decides what it shows. It’s now also easier to test and reuse, because everything it does is visible in its props.
Notice the shape. Data flows down the tree as props: movies, filter, visible. Changes flow up as function calls: the form calls onAdd, the filter bar calls onChange. Only App ever calls setMovies or setFilter.
That’s the payoff. If the list ever shows the wrong movies, there’s exactly one place that decides what’s in it. You follow the props up to their owner and read the code that changes them. Compare that with an app where any component can poke any other: a bug could come from anywhere.
\nLook at what’s not state, too. visible is calculated from movies and filter on every render, and Header derives its count from movies. Lifting state doesn’t mean lifting everything; it means one owner for each piece of real state, and everything else derived from it.
You rarely plan every piece of state perfectly up front. You discover the need to lift while building, and the signs are consistent:
\nEach of these means the same data has two owners, or the owner is too low in the tree. Lifting is a small, mechanical refactor: cut the useState line, paste it into the parent, and replace the old state in the child with props.
Lifting has a cost: the owner re-renders when the state changes, along with its children, and props have to travel further. So don’t lift everything to App by reflex.
The text being typed into the title field is a good example. Only AddMovieForm cares about it while you type. App only needs the finished title, which it gets from onAdd. So the draft stays in the form. If later some other component needed to preview the draft, you’d lift it then.
When state needs to be read by components far apart in the tree, passing it through every level becomes tedious. You saw one fix in the composition lesson (pass elements down), and React’s context is the other. For the Watchlist, a few props are all you need.
\n\nYour Watchlist now has one source of truth and three components that read and change it. Next, you’ll sync that state with something outside React, the browser tab’s title and localStorage, using effects.
\n","toc":[{"id":"sec-1","text":"The problem: siblings can’t share","level":2},{"id":"sec-2","text":"The fix: lift it to the common parent","level":2},{"id":"sec-3","text":"Data down, events up","level":2},{"id":"sec-4","text":"Signs you need to lift","level":2},{"id":"sec-5","text":"As low as possible, as high as necessary","level":2}],"takeaways":["When two components need the same changing data, move the state to their closest common parent and pass it down as props.","Children change shared state by calling handler props such asonAdd or onFilterChange; data flows down and events flow up.","Keep each piece of state as low in the tree as possible but as high as necessary.","Don’t copy a prop into state with useState(prop); the copy ignores later changes. Use the prop directly or derive from it."],"further":[{"title":"Sharing State Between Components","url":"https://react.dev/learn/sharing-state-between-components"},{"title":"Choosing the State Structure","url":"https://react.dev/learn/choosing-the-state-structure"}],"quiz":[{"q":"FilterBar keeps const [filter, setFilter] = useState('all'). MovieList, its sibling, needs to show only the movies matching the filter. What’s the fix?
filter to both, and pass setFilter (or a handler) to FilterBar.","why":"Correct. One owner, one source of truth. FilterBar shows and changes the value; MovieList reads it."},{"text":"Make MovieList a child of FilterBar so it can read the state.","why":"Rearranging the UI tree to fit data is backwards, and the header that counts movies would still be left out."}],"answer":2},{"q":"Which piece of Watchlist state should stay inside AddMovieForm rather than being lifted to App?
onAdd."},{"text":"The list of movies.","why":"The header, the list and the form all depend on the movies, so they belong in App."},{"text":"The current filter.","why":"Both the filter buttons and the list need it, so it lives in their common parent."}],"answer":0},{"q":"MovieTitle shows a title it receives as a prop. When the parent renames the movie, the child keeps showing the old title. Why?
function MovieTitle({ title }) {\n const [text] = useState(title);\n return <h2>{text}</h2>;\n}onChange handler.","why":"Headings don’t have change events. The issue is where the text comes from."},{"text":"useState only uses its argument on the first render, so text is a frozen copy. Render {title} directly.","why":"Correct. The initial value is read once. If the component doesn’t need to edit the value, it shouldn’t copy it into state."}],"answer":3},{"q":"In the Watchlist, data flows down as props and changes flow up through callbacks. What’s the main benefit of this one-way flow?
","options":[{"text":"It makes React render faster than two-way binding.","why":"Performance isn’t the point; the benefit is about understanding and debugging your app."},{"text":"To find out why something shows a value, you follow props up to the one component that owns the state.","why":"Correct. Every piece of state has one owner, and only that owner changes it, so bugs have one place to look."},{"text":"It removes the need for event handlers.","why":"Callbacks are event handlers passed down. One-way flow depends on them."}],"answer":1}],"exercise":{"kind":"web","mode":"react","starter":{"jsx":"import { useState } from 'react';\n\nconst MOVIES = [\n { id: 'a1', title: 'Arrival', watched: true },\n { id: 'p2', title: 'Past Lives', watched: false },\n { id: 'd3', title: 'Dune: Part Two', watched: false },\n];\n\nfunction MovieList({ movies }) {\n return (\nThe filter buttons highlight correctly, but the list never changes, because FilterBar keeps the filter to itself.
Lift the filter state into App. Pass the current value and a way to change it down to FilterBar (it should have no state of its own), and give MovieList only the movies that match:
watched is falsewatched is trueKeep aria-pressed on the buttons working.
const [filter, setFilter] = useState('all') from FilterBar into App.","Give FilterBar two props, for example value and onChange, and use them in place of its old state.","In App, derive the list: MOVIES.filter((m) => filter === 'all' ? true : filter === 'watched' ? m.watched : !m.watched)."],"explanation":"State is private to the component that declares it, so a sibling can never read it. Moving filter to App, the closest common parent, gives it one owner. FilterBar becomes a controlled component that shows value and reports clicks through onChange, and App derives the visible movies from MOVIES and filter on every render instead of storing a filtered copy.