Giter Club home page Giter Club logo

Comments (4)

simonihmig avatar simonihmig commented on July 21, 2024

Hm, that's weird, didn't know of that behaviour!

Wouldn't be opposed to it, if you want to contribute this!? 😉

The API of your example would only allow to mock a property on the root level of window, but we also wrap nested objects in Proxies to enable overriding readonly sub-properties (like window.navigator.userAgent). That wouldn't be possible in this case, unless you want to enable something like mock('foo.bar', ...), which would probably be difficult to implement. Don't know if there is a real-world use case though?

Alternatively maybe add some method to any Proxy we create, like window._mock('document', ...), as this would also allow window.foo._mock('bar', ...).

from ember-window-mock.

buschtoens avatar buschtoens commented on July 21, 2024

Hm, that's weird, didn't know of that behaviour!

I also did not know before. 😅

Wouldn't be opposed to it, if you want to contribute this!? 😉

Sure, I'd love to!

The API of your example would only allow to mock a property on the root level of window, but we also wrap nested objects in Proxies to enable overriding readonly sub-properties.

Good point. I usually tend to avoid mocking things partially, but I guess especially for window and its sub-properties this does not really apply, so we should support a way to do this.

Alternatively maybe add some method to any Proxy we create

I thought about that too, but rejected it, because it would change the behavior of code that iterates over properties on objects. We also can't guarantee, that users / libraries might not already use the _mock key.

I'd either allow specifying paths, like you suggested, or allow the user to pass the target proxy as the first parameter:

mock(window.document, 'querySelector', (selector) => ...);

But I think I prefer:

mock('document.querySelector', (selector) => ...);

from ember-window-mock.

buschtoens avatar buschtoens commented on July 21, 2024

Another alternative would be a function to retrieve the holder for any proxy from a WeakMap:

import window, { getHolder } from 'ember-window-mock';

module('foo', function(hooks) {
  hooks.beforeEach(function() {
    class DocumentMock extends EventTarget {
      // ...
    }

    getHolder(window).document = new DocumentMock());
  });
});

Also tangentially related: I think it would reduce complexity, if we'd remove all the special handling here and just assign these properties to the holder:

https://github.com/kaliber5/ember-window-mock/blob/fa60f4119a36a39cbc8c7ce4fcdfea9249d5e913/addon-test-support/-private/window.js#L18-L25

This would then also allow users to mock objects like location through the holder.

from ember-window-mock.

simonihmig avatar simonihmig commented on July 21, 2024

Another alternative would be a function to retrieve the holder for any proxy from a WeakMap:

I think I would prefer the mock function. Exposing the holder directly leaks too much of the (Proxy-based) implementation into the API IMHO. Also having the mock() we would have more control, maybe later add some checks, so not everything can be mocked or whatever.

Also tangentially related: I think it would reduce complexity, if we'd remove all the special handling here and just assign these properties to the holder

Agree, good point!

I thought about that too, but rejected it, because it would change the behavior of code that iterates over properties on objects.

Haven't thought much about the implementation yet. But re: iterating, you could define it as not enumerable I think, or expose that function through the Proxy's get-handler maybe? Just thinking aloud, but I guess it should be doable to hide that function from enumeration!?

It would probably make having access to the holder easier, as you could closure over it (is that how you call it, I have no idea!? 😂). Otherwise you would probably have to apply that WeakMap approach you mentioned, or assign some private property (Symbol) to the Proxy, so mock() gets hold of the holder 🙃.

from ember-window-mock.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.