Closed chrissloey closed 8 years ago
Whenever i've been working with sinon, i've had no problem mocking out window. Personally I use jsdom
to mock it, and then grab the window out of that. If the mock is an actual mock of window, and not something you make up, it should work fine with most libraries
Thanks for the tip! It looks like jsdom
doesn't implement cancelAnimationFrame, but I got things working by using jsdom and stubbing cancelAnimationFrame on top of it.
This still feels like a problem with react-native-mock
though - I can submit a PR if you have a preference for fixing it. I think it should just be removed but if there's a reason it's there, there should at least be some docs around it or even a stub for cancelAnimationFrame
to prevent exceptions.
I like the idea of fixing it, but I think having jsdom in the project too is a little much, considering others may want a different approach. I think the best solution would be validating that the function is actually there: if (window && window.cancelAnimationFrame) ...
?
Agreed on jsdom. After my last comment I realised the code as it is (with reference to window
) is straight from React Native's AnimatedImplementation
so probably fair to leave it there and guard it as you suggest.
Will submit a PR later today. I have some other Animated
related things I'm mocking that I'll submit a PR for separately too.
There are two calls to
window.cancelAnimationFrame
in AnimatedImplementation.js.This causes
ReferenceError: window is not defined
when I run my tests, and I can't mockwindow
because other libraries (like sinon) enable React Native compatibility by checking forwindow
.