Provide prelude about async-graphql

[sunli829]

I think so too, when I finish the job at hand, because I have added some new types. 😂

[IcanDivideBy0]

Just to give a hint on what should be in prelude, currently my project is not that much advanced but this might help a bit:

$ grep -irn 'use async_graphql' src

use async_graphql::{Context, FieldResult, ID};
use async_graphql::{Context, FieldResult, ID};
use async_graphql::{guard::Guard, Context, FieldResult, ID};
use async_graphql::{Context, FieldResult, ID};
use async_graphql::{Connection, Context, DataSource, FieldResult, ID};
use async_graphql::ID;
use async_graphql::{Connection, Context, DataSource, FieldResult, ID};
use async_graphql::SimpleBroker;
use async_graphql::{Connection, Context, Cursor, DataSource, EmptyEdgeFields, FieldResult, QueryOperation}
use async_graphql::FieldResult;
use async_graphql::{Json, ID};
use async_graphql::extensions::ApolloTracing;
use async_graphql::http::{playground_source, GQLResponse};
use async_graphql::{Data, QueryBuilder, Schema};

I personally write macros with full path, eg #[async_graphql::Object] I feel that having just #[Object] on top of the declaration is a too much generic name, if macros were renamed #[GraphQLObject] I think I'll go for this style.

So I'd definitly put Context, FieldResult, FieldError, InputValueError, InputValueResult ID for sure

Connection, Cursor et al is really tied to Relay, the usage seems pretty wide on the different places I worked with graphql tho, even if most of the time it's the only part of the spec that is used

[sunli829]

Good suggestion, I will make a list tomorrow. 😊

[phated]

Just my input, I think custom scalars and relay stuff shouldn't exist in the prelude. It would be very nice to have async_graphql::relay::prelude::* and async_graphql::custom_scalars::prelude::*

[IcanDivideBy0]

@phated I don't think relay and custom scalars need their own prelude, there's not much in those modules, they can be used as async_graphql::relay::* and async_graphql::scalars::*