Why does a second `cy.mount()` in one Cypress test reset the component's state?

Two things a component test wants look almost identical in the spec file and are not the same operation at all: **mounting a component with different props** and **changing the props of a component that is already mounted**. The first proves the initial-render path; the second proves the update path. `cy.mount()` only ever does the first. ## Mount is not re-render Calling `cy.mount()` a second time inside one test does not hand new props to the instance on screen. It tears that instance down and builds another one. Everything the component was holding — selected rows, an open menu, an uncommitted input value, a running timer captured in a closure — is gone. Between tests Cypress unmounts for you anyway, so this behaviour only ever bites inside a single test. ## What the React adapter actually does As of Cypress 16, `mount` from `cypress/react` performs three things in order before it renders anything: 1. **Cleanup.** It unmounts the previously created React root, if there is one. The source comment says why in plain terms: React would otherwise merely replace the last component, and the adapter wants the root gone "to wipe away any state". 2. **A new root.** `ReactDOM.createRoot()` runs against the mount container element. 3. **A new key.** The tree is wrapped in a fragment carrying a generated `key` — the current test title plus a random number — unless an explicit rerender key is supplied. A changed `key` tells React to discard the old subtree rather than reconcile with it. Each of the three, on its own, would be enough to reset state. Together they make the guarantee unambiguous: a mount is always a fresh start. ## Getting a real prop change `cy.mount()` yields a `MountReturn` object, not a DOM element. In the React adapter that object carries `component` (what was rendered) and `rerender` (a function that re-renders new JSX **on the same root, under the same key**): ```js cy.mount(<DataGrid rows={rows} density="comfortable" />).then(({ rerender }) => { cy.get('[data-cy=row-3]').click() cy.get('[data-cy=row-3]').should('have.attr', 'aria-selected', 'true') rerender(<DataGrid rows={rows} density="compact" />) // the selection survives, because the instance did cy.get('[data-cy=row-3]').should('have.attr', 'aria-selected', 'true') }) ``` Because `rerender` skips the adapter's cleanup and reuses the key, React reconciles instead of remounting — which is exactly the production behaviour a density toggle or a locale switch triggers. ## What each adapter yields | Adapter | `cy.mount()` yields | Update the mounted instance with | | --- | --- | --- | | `cypress/react` | `{ component, rerender }` | `rerender(newJsx)` | | `cypress/vue` | `{ wrapper, component }` | Vue Test Utils' `wrapper.setProps()` | | `cypress/svelte` | `{ component }` | no update helper is provided | The lesson generalises: before you assume a re-render is available, look at what the adapter you are using actually hands back. Aliasing the yield with `.as('grid')` early in the test keeps it reachable without nesting everything inside one `.then()`. ## When a second mount is the right tool - **Initial-render assertions.** Mounting a rating widget once with `value={0}` and again with `value={4}` checks that first render honours the prop, which a re-render would not exercise. - **Resetting deliberately.** When the point of the test is that the component starts clean, re-mounting states that intent better than clicking your way back. - **Different configurations of the same tree.** A toast mounted with and then without an action region. Even then, two separate `it` blocks usually read better: with two mounts in one test, a failure message does not say which mount it came from. ## Reading the symptom The tell-tale is a test that "loses" something it just did: - A row was selected, the grid was mounted again with a new prop, and the selection is gone. - A spy that was called before the second mount is still aliased and still holds its calls — spies are not remounted with the component, so a stale `have.been.calledOnce` can pass for the *previous* instance's work. - An input's typed value disappears between two mounts in one test. None of these is flake. They are the adapter doing exactly what it documents, and the fix is `rerender`, `setProps`, or splitting the test in two.