Also what do you mean by tested as field of input/output type? Does that mean as field of a struct using the #[derive(GraphQLObject)] macro?

@chirino yes

#[derive(GraphQLInputObject)]
struct InputObj {
    val: serde_json::Value,
}

struct Human;

#[graphql_object]
impl Human {
    fn output() -> serde_json::Value {
    }

    fn input(arg: serde_json::Value) -> bool {
    }

    fn input_object(obj: InputObj) -> bool {
    }
}

Sadly we can't do something as simple as:

#[derive(GraphQLInputObject)]
struct InputObj {
    val: serde_json::Value,
}

Since we need a way to associate type info with the val field. I did included a test that shows how you can create a wrapper type around serde_json::Value that provides that type info.. but it's a bit verbose. Not sure if there is a way to reduce that.

Do you have an example of how you test the subsctiption return type case?

@chirino

I did included a test that shows how you can create a wrapper type around serde_json::Value that provides that type info.

Does it worth to have such a wrapper predefined?

Do you have an example of how you test the subsctiption return type case?

See integration_tests/juniper_tests/src/codegen/subscription_attr.rs.

@tyranron

I think the PR should have about the right stuff covered in the tests. It introduces a couple of new public types... and naming things is hard so let me know if you can think of better names for:

• TypeInfo
• TypedJsonInfo
• TypedJson

Also not sure where to document this in the book.

@chirino go with the names you think are best. I'll bikeshed them in the final review if a better naming will come up in my mind.

Also not sure where to document this in the book.

I think it would be nice to create a separate page in advanced topics.

Minor nit, but we probably want to match the integration crate name with the integration file name with the flag name. That is, serde_json everywhere instead of json.

renamed and added a section to the book. Is anything else needed?

@chirino thanks! I'll look at it in few days.

This is great work, thank you! ❤️

Just to keep everybody up-to-date:
This PR is not abbandoned. I'm working on it right now to extend the work dony by @chirino. It will take quite a while, because the rabbit hole appeared to be deeper than expected.

@tyranron thanks for the update. Do you have a branch of your work that I can peek at? Maybe I can find some time to help.

@chirino unfortunately no, but thank you. You've already done so much 🙇‍♂️

I just need to somewhat extend that, fix some edge cases and polish. It will be harder to explain than do and finish.

Wow, this PR has turned to be such a huge rabbit hole 😅
It has spotted so many juniper design weak points. And some of them I intend to fix in separate PRs before merging this.

Sorry for moving it slowly, but I'd like to do it the proper way from the start, rather than having it half-baked or redoing in future.

No rush. Glad my "first ever rust PR" is nudging this project even to become even better.

@tyranron hey.. I know this is a complex PR and I'm a noob, but feel free to reach out to me if you need help with it.

@tyranron are you still planning on working on this PR? Super excited to get serde_json integration

@juancampa yes, of course. It's scheduled for 0.16.0 release. But it requires first the #1072 to be completed, as at the moment there is no way to combine dynamic GraphQL schema with a static one, due to TypeInfo being an associative type, so allowing no polymorphism.

@tyranron should I close this PR out?