Some questions

[jxnu-liguobin]

Some of the code is unclear and wants to be explained.

1. The class generated by this macro is used to associate fragment with query?

            quote! {
                pub fn select<'a, T: 'a + Send + Sync>(
                    self,
                    fields: ::cynic::selection_set::SelectionSet<'a, T, #argument_type_lock>
                ) -> ::cynic::selection_set::SelectionSet<'a, #decodes_to, super::#type_lock>
                    {
                        ::cynic::selection_set::field(
                            #query_field_name,
                            self.args,
                            #selector
                        )
                    }
            }

I also noticed another macro generated class, which seems to want to automatically implement any framgment. What's the relationship between them

            #[automatically_derived]
            impl ::cynic::InlineFragments for #target_struct {
                type TypeLock = #type_lock;
                type Arguments = #arguments;

                fn fragments(context: ::cynic::FragmentContext<'_, Self::Arguments>) ->
                    Vec<(String, ::cynic::SelectionSet<'static, Self, Self::TypeLock>)>
                {
                    use ::cynic::QueryFragment;

                    let args = context.args;

                    let mut rv = vec![];
                    #(
                        rv.push((
                            #internal_types::graphql_type(),
                            #internal_types
                                ::fragment(context.with_args(::cynic::FromArguments::from_arguments(args)))
                                .map(#target_struct::#variants)
                                .transform_typelock()
                        ));
                    )*
                    rv
                }

                fn graphql_type() -> String {
                    #graphql_type.to_string()
                }

                fn fallback(context: ::cynic::FragmentContext<'_, Self::Arguments>) ->
                  Option<::cynic::SelectionSet<'static, Self, Self::TypeLock>>
                {
                    #fallback_selection
                }
            }

2. possible_ types function, Why need
3. Provide method/struct description for the library, create an issue for it?
4. Maybe other question in the future.

I have understood the main functions and structure of the library, but it is still very difficult for the existing macros, but I have learned a lot now. Thank you very much. I will continue. @obmarg

[obmarg]

Some of the code is unclear and wants to be explained.

1. The class generated by this macro is used to associate fragment with query?

            quote! {
                pub fn select<'a, T: 'a + Send + Sync>(
                    self,
                    fields: ::cynic::selection_set::SelectionSet<'a, T, #argument_type_lock>
                ) -> ::cynic::selection_set::SelectionSet<'a, #decodes_to, super::#type_lock>
                    {
                        ::cynic::selection_set::field(
                            #query_field_name,
                            self.args,
                            #selector
                        )
                    }
            }

So this code is part of the query_dsl, which gets output by the query_dsl!("some_schema_file.graphql) macro call in any code that uses cynic. The job of the query_dsl is to take a GraphQL schema and generate functions (and types) that can be used to build queries against that schema. The various derive macros (QueryFragment, InputObject, Scalar etc.) then use these types & functions to actually build the queries.

Each composite field in the schema will end up with one of those select functions (which itself is on a specially output "SelectionBuilder" struct). It takes a single parameter that is the SelectionSet of fields to select from that composite and outputs a SelectionSet that will pick that field (and it's sub-fields), passing in any arguments that have been provided to the selection builder so far.

I also noticed another macro generated class, which seems to want to automatically implement any framgment. What's the relationship between them

            #[automatically_derived]
            impl ::cynic::InlineFragments for #target_struct {
                type TypeLock = #type_lock;
                type Arguments = #arguments;

                fn fragments(context: ::cynic::FragmentContext<'_, Self::Arguments>) ->
                    Vec<(String, ::cynic::SelectionSet<'static, Self, Self::TypeLock>)>
                {
                    use ::cynic::QueryFragment;

                    let args = context.args;

                    let mut rv = vec![];
                    #(
                        rv.push((
                            #internal_types::graphql_type(),
                            #internal_types
                                ::fragment(context.with_args(::cynic::FromArguments::from_arguments(args)))
                                .map(#target_struct::#variants)
                                .transform_typelock()
                        ));
                    )*
                    rv
                }

                fn graphql_type() -> String {
                    #graphql_type.to_string()
                }

                fn fallback(context: ::cynic::FragmentContext<'_, Self::Arguments>) ->
                  Option<::cynic::SelectionSet<'static, Self, Self::TypeLock>>
                {
                    #fallback_selection
                }
            }

So this one is specifically for querying interfaces & union types. You're maybe aware that if you've got an interface or a union type in GraphQL then you need to use inline fragments to select fields from concrete types, like this:

some_interface_field {
   ... on SomeType {
     aField
   }
   ... on SomeOtherType {
      aDifferentField
   }
}

We support this sort of thing in cynic with this InlineFragments derive, like so:

#[derive(InlineFragments)]
enum SomeInterfaceField {
   SomeType(SomeConcreteType),
   SomeOtherType(SomeOtherType)
}

#[derive(QueryFragment)]
struct SomeType {
   a_field: String
}

#[derive(QueryFragment)]
struct SomeOtherType {
   a_different_field: String
}

That derive(InlineFragments) ends up outputting the code you quoted, which decodes the appropriate enum variant based on the __typename that comes back from the server.

1. possible_ types function, Why need

We need the possible_types as an InlineFragments can decode to one of several different types. Without this we wouldn't know which types were possible.

2. Provide method/struct description for the library, create an issue for it?

I do have this issue which is close: #180

Although not sure whether that will end up covering the codegen, it was originally just for the user facing docs.

[jxnu-liguobin]

Thank you for your detailed explanation, but I'm still a bit confusing. Maybe I need to continue to solve some problems.