Add ability to specify local mock file

[just-be-dev]

First off, this project is amazing. It's extremely useful for bootstrapping an app before the graphql server exists.

The faker methods are extremely useful, but I'm finding myself wishing I could run custom code to generate what I need in certain scenarios.

What if there was something like this

schema.faker.graphql

type JiraIssue {
  id: ID @fake(type: uuid)
  key: String @fake(type: mock, func: "jiraIssue")
}

graphql-faker-mocks.js

// Imagine this function does something more exciting
export const jiraIssue = () => 'ABC-123'

The semantics here might not be great. It could be a separate directive or the parameters could be different. Ultimately the idea is just to be able to custom mocks.

[IvanGoncharov]

Great idea 👍
But I think it's better to have a separate directive for it.
Like @fakeFunc it will allow for more flexibility and keep @fake from bloat.
For example, you can add support for arguments:

@fakeFunc(name: "jiraIssue", args: ['ABC', 1, 123])

// Imagine this function does something more exciting
export const jiraIssue = (prefix, min, max) => prefix + '-' + randomInt(min, max)

However, I would treat this feature only as the last resort for the cases when you have something very specific to you project.
Can you please describe your use case in more details?
What type of data are you trying to fake?

[just-be-dev]

Specific metadata from git, jira, jenkins currently. I've actually got functions that already generate this sort of data for my tests anyway, so all I'd need to do is hook it up.

I agree with your recommended changes. My try my hand at a PR tonight.

[IvanGoncharov]

My try my hand at a PR tonight.

@zephraph Would be great ❤️, just create PR when you will have proof of concept.

[kuncevic]

Yeah I see the use case where you need a constant predicted result, this might be useful for writing unit tests. Any progress on that @zephraph ?

[IvanGoncharov]

Yeah I see the use case where you need a constant predicted result

@kuncevic If you interested in just having predictable results for existing @fake directives, then I think allowing to specify a seed for the random number generator would be a better option.
What do you think?

[kuncevic]

@IvanGoncharov I am just not sure if having specifying the seed will cover all the use cases or does it?

[IvanGoncharov]

@kuncevic As I wrote before I totally for this feature, but I would like this feature to be used only as the last resort for the cases when you have something very specific to your project.

Yeah I see the use case where you need a constant predicted result

If you just want to get the same result for the same query than having the ability to provide seed for the entire query could be a better solution. But if you want to have different queries to return subselections from the same data then it's a completely different story.

[dguay]

Any news on this? It would be really interesting to be able to call a custom function to generate mock data for @fake and @examples directives.