How does a Vue 3 composable differ from a React custom hook in when its code runs and how it tracks dependencies?

## Two models that look alike Vue's Composition API was partly inspired by React hooks, and a composable such as `useCounter()` looks like a custom React hook: a `use`-prefixed function that creates state and returns it. The resemblance ends at the execution model, and interviewers use the comparison to check whether a candidate understands Vue's. ## How often the code runs - **React, public model:** a function component's body runs on every render, and so does every hook it calls. React matches each hook call to its stored state by the order of the calls, which is why hooks may not be called conditionally. Closures created during one render see that render's values. - **Vue:** `setup()`, or the top level of `<script setup>`, runs **once per component instance**. A composable called there runs once. Its refs are ordinary variables captured in closures, and because the ref object is the same for the component's whole life and `.value` always reads the current value, those closures do not go stale. Re-rendering the component re-runs only its render function, not setup. ## How dependencies are tracked - **React:** effects and memoised values take an explicit **dependency array**. Getting it wrong produces stale values or extra runs, and a lint rule is commonly used to police it. - **Vue:** `computed()`, `watchEffect()` and each component's render effect record which reactive values they read while running, and re-run only when one of those changes. There is no dependency list to maintain. `watch()` does take an explicit *source*, but that is a choice of what to observe, not a list that must be kept in sync with the body. ## Consequences for writing composables | Concern | Vue composable | React custom hook | |---|---|---| | Body execution | once, during setup | on every render | | Stale closures | not an issue for refs | a common bug class | | Dependency lists | none; tracked automatically | written by hand for effects and memoisation | | Conditional call | allowed; evaluated once at setup | not allowed | | Memoising callbacks passed to children | rarely needed | often needed to avoid child re-renders | The last row follows from fine-grained tracking: a Vue child component re-renders when reactive state it read changes, or when its props change, not merely because a new function object was created in the parent on every render, since the parent's setup code does not re-run. ## Where Vue has its own rules Running once does not mean "call it anywhere". A composable must still be called **synchronously during setup** (or inside a lifecycle hook), because that is when Vue knows which component instance is active and can attach the composable's lifecycle hooks and watchers to it. Call it from a click handler and its hooks are not registered. And because setup runs once, a condition around a composable call is evaluated once: `if (props.compact) useResize()` decides at creation time and does not re-evaluate if the prop later changes. When behaviour must follow a changing prop, pass the prop in as a getter and let the composable watch it. ## How to answer in an interview 1. Name the shared idea: both extract stateful logic into `use` functions that compose. 2. State Vue's execution model: setup and the composables it calls run once; refs hold current state. 3. State Vue's tracking model: automatic dependency collection, no dependency arrays. 4. Name the consequences: no stale closures over refs, no call-order rule, little manual memoisation. 5. Name Vue's own constraint: a synchronous call during setup, and conditions that are decided once. Describe React at the level of its public model only. The point of the question is to show you know what Vue does, not to recite React internals.