Add parameter to be able to filter type fields by passing a query document

[AlexPla]

I've been using this library and I think it's amazing, so thank you for your contribution.

I've been having performance problems using it in my project since we have gigantic schemas with lots of attribute levels which make it impossible for us to use mock functions because it consumes the whole heap memory while we run tests due to it generating a lot of unnecessary data.

We've been dealing with that using the relationshipsToOmit parameter, but it's often too verbose and I've thought about a potential solution that I want to present.

What I suggest is to add a new parameter to the top level aQuery function which should be a graphql query DocumentNode, which would be used to prevent the mock function from generating unnecessary objects if those fields are not present in that query response.

I've opened a PR with a potential implementation (of course, open to any change suggestion if you find this could be a nice addition to the plugin but can be done in a better/more suitable way): https://github.com/ardeois/graphql-codegen-typescript-mock-data/pull/98

Previously I tried to generate new functions for each query using the documents parameter of the plugin function but I couldn't find a way of doing that, maybe there is one and it'd be better that way, but that'd be generating new mock functions for each query and I'm not sure if I prefer that to the document parameter solution.

Thank you!

[zekenie]

I also just found this library and I'm excited about it. I'm running into exactly the same issue. What if relations could be lazily loaded when they're accessed through a proxy? I know that sounds like a pretty different strategy, but it could allow for a "batteries included" and fast solution that works with large schemas

[ardeois]

Sorry for the late reply @AlexPla I understand your issue, but I wonder if using passing a DocumentNode to aQuery is the best option here

I would actually challenge the existence of aQuery itself as nobody want to mock the whole query properties indeed.

What if instead we get rid of aQuery and we create one mock function for each query type.

For example, if we had this schema:

    type Query {
        A: A
        B: B
    }

    type A {
        a1: String!
    }

    type B {
        b1: String!
    }

we could create the following mock functions for query type:

const aQueryA = () => ...

const aQueryB = () => ...

This way we don't have aQuery function that generates all possibilities

Ideally, we should be able to create mock function based on documents parsing (like typescript plugins does for fragment matchers, queries etc) but that's more work

What do you think? Would splitting the query object to one mock per property work for your use case?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mjlikre]

would be nice if we merge this one in