https://cypress.io logo
#help
Title
# help
b

busy-vegetable-18177

06/04/2022, 11:50 AM
I made a custom assertion that checks if an element is in the viewport (fails if need to scroll to it), and I want to execute it by default before clicking on anything. So I added this:
Copy code
js
Cypress.Commands.overwrite("click", (originalFn, subject, options) => {
  if (options !== undefined && options.scroll) {
    originalFn(subject, options)
  } else {
    cy.wrap(subject).should("be.in-viewport").then(() => originalFn(subject, options))
  }
})
But this gives me an error on another part of the code saying
Copy code
Cypress detected that you returned a promise from a command while also invoking one or more cy commands in that promise.

The command that returned the promise was:

  > cy.clear()

The cy command you invoked inside the promise was:

  > cy.wrap()

Because Cypress commands are already promise-like, you don't need to wrap them or return your own promise.

Cypress will resolve your command with whatever the final Cypress command yields.
I don't understand, what am I doing wrong? I'm not returning a promise...
w

wonderful-match-15836

06/04/2022, 9:10 PM
I'm gonna take a closer look but I know Gleb has a helpful video about this subject so as a starting point this is worth checking out

https://www.youtube.com/watch?v=LV9Hm0cQ_lQ

> this gives me an error on another part of the code Can you give some more context for this? What's the exact usage that leads to this error? Does it only happen when using
cy.click()
and passing
{scroll: false}
? I like the custom assertion btw.
b

busy-vegetable-18177

06/04/2022, 9:35 PM
This is my test (edited)``` -snip- ```
as you can see the
click
is probably the one on
be.visible
from before that
I don't think the video helps me much because I never create my own Promise and it doesn't show how this works with a custom command
Gimme a sec I'll make a smaller test
This looks like it's also happening with
scroll: true
scrap this, wasn't passing it correctly
Is there any example working code for this kind of thing out there?
w

wonderful-match-15836

06/04/2022, 9:52 PM
I am a little puzzled as I was able to overwrite click without a problem just now 🤔. Let me look at those issues for a second. What version of Cypress are you using by the way? Based on the error, it looks more like these lines are the problem, not the custom command, for what it's worth:
Copy code
cy.get("[data-cy-edit-form-name=Gunjo]").within(() => {
      cy.get("input[name=name]").clear().type("Gunjont") // <- here
    })
b

busy-vegetable-18177

06/04/2022, 9:52 PM
cypress10.0.1
the error comes from that line but if I revert the click override then it doesn't happen anymore
I'll see if it happens if I only .clear() though
yeah I can reproduce it with this
Copy code
js
    cy.visit("/")
    cy.get("input[name=search]").clear()
w

wonderful-match-15836

06/04/2022, 9:54 PM
yeah I'm seeing the same thing, if I am overriding
click
in this way, I get the error. Which makes me think maybe
clear
is using
click
b

busy-vegetable-18177

06/04/2022, 9:54 PM
this also happens with type()
w

wonderful-match-15836

06/04/2022, 9:54 PM
pretty sure type also uses
click
internally to ensure the element you are typing into has focus, need to double check
b

busy-vegetable-18177

06/04/2022, 9:55 PM
guess ill just add a new one instead ¯\_(ツ)_/¯
or slap the assertion on everything
w

wonderful-match-15836

06/04/2022, 9:57 PM
yeah that would be safer, I feel we should either warn when a user is overwriting
click
, or make an internal private
click
that other commands use. Not sure what's best. But
clear
on a form field is an alias for
.type({selectall}{backspace})
so if
click
is invoked when you
type
it's also invoked when you
clear
yeah that gh issue you linked explains the same thing. I would sorta recommend just naming your command
clickIfInViewport
or something to surface the fact this this does not behave the same way as
cy.click()
anyway, since new developers coming to your project with existing Cypress experience might not easily discover that you've implemented a different behavior.
b

busy-vegetable-18177

06/04/2022, 10:07 PM
Yeah that's a good idea. Also I'm looking through my tests and I assumed that most of the time I would want to fail if the element is outside of the viewport but actually most of the time I do want the scrolling behavior. The problem is that for some reason this scrolling extends to elements that are scrolled out to the right of the screen but I only want it to go up or down
but yeah I'll just catch those individually
4 Views