Are aliased elements returned without re-querying in some cases?

[alexeyr-ci2]

1. https://docs.cypress.io/app/core-concepts/variables-and-aliases#Elements says

Because we've used the @ character in cy.get(), instead of querying the DOM for elements, cy.get() looks for an existing alias called rows and returns the reference (if it finds it).

2. But https://docs.cypress.io/app/core-concepts/variables-and-aliases#Stale-Elements:

Every time we reference @firstTodo, Cypress re-runs the queries leading up to the alias definition.

They could not contradict each other because the same section mentions

The previous <li> has been completely removed from the DOM and a new <li> is rendered in its place.

So maybe the existing reference is used if the element is not completely removed? And we are sometimes getting detached elements despite using correct chaining (and without .as(..., { type: 'static' })).

But https://docs.cypress.io/app/references/migration-guide#Behavior-Changes-in-Alias-Resolution seems to say 2 is in fact correct without this qualification:

Cypress always re-queries aliases when they are referenced.

[tamish-max]

@{owner=cypress-io; name=cypress; number=33806; body=My reading is:

• for DOM aliases, the default is effectively a query alias
• so cy.get('@rows') re-runs the chain that produced the alias
• if you want the frozen value/reference, you opt into { type: 'static' }

So these two docs are reconcilable: the alias name is looked up first, but for a DOM/query alias Cypress resolves it by replaying the query chain, not by handing you the exact old node forever.

Where detached-element errors still happen is usually after you got the alias, when an action causes the DOM to re-render and you keep chaining on the stale subject:

cy.get('li.todo').first().as('firstTodo')

cy.get('@firstTodo').click()     // click may trigger re-render
cy.get('@firstTodo').should('contain', 'done') // re-query: good

vs

cy.get('@firstTodo')
  .click()
  .should('contain', 'done') // same chain, stale subject risk after click

If the element is expected to change/remount, I’d split the chain and re-query after the DOM-changing action. And if you truly want a snapshot, use:

cy.get('li.todo').first().as('firstTodo', { type: 'static' })

So short answer: no, I would not rely on aliased DOM elements being returned “without re-querying” in modern Cypress.}.body

[alexeyr-ci2]

no, I would not rely on aliased DOM elements being returned “without re-querying” in modern Cypress.}

I actually wanted to know if I can rely on them always being re-queried (which was my understanding before noticing the first point).

Where detached-element errors still happen is usually after you got the alias, when an action causes the DOM to re-render and you keep chaining on the stale subject

By "And we are sometimes getting detached elements despite using correct chaining" I meant that:

1. We use the ESLint rule banning cy.get('@firstTodo').click().should('contain', 'done') https://github.com/cypress-io/eslint-plugin-cypress/blob/master/docs/rules/unsafe-to-chain-command.md;
2. I did look at the stack trace and not see anything like such a chain (and remember being quite annoyed by the generic message https://docs.cypress.io/app/references/error-messages#cy-failed-because-the-page-updated instead of saying what does it think the actual chain is).

Still, the last time it happened was quite a bit of time ago and couldn't be reproduced now.

[jennifer-shehane]

I made some updates to the docs here that hopefully clears up some of the confusion here: cypress-io/cypress-documentation#6539

[alexeyr-ci2]

Thank you!