Adding support for multiple input types (multiple factories) for one input type about graphqlite HOT 8 CLOSED

Is this also possible to nest Filter? cause it's not explained. E.g.

class ExtendedFilterType {
    /**
     * @Decorate(name="FilterWithColorInput")
     * @UseInputType(for="$nestedRelationFilter", name="NestedRelationFilterFactory")
     */
    public function createFilterWithColor(Filter $filter, Filter $nestedRelationFilter): Filter
    {
        $filter->addFilter('weight', '<', $maxWeight);
        $filter->addRelationFilters($nestedRelationFilter);
        return $filter;
    }
}

from graphqlite.

Also it doesn't actually say what happens with the input. Is it optional? Cause we can have 10 filters, but use only one in query.

from graphqlite.

Is this also possible to nest Filter?

Of course. It is already possible to nest an input type into another input type today. Since this is already supported, I did not write it explicitly.

Also it doesn't actually say what happens with the input. Is it optional? Cause we can have 10 filters, but use only one in query.

Yes, this is already something that GraphQLite can do today. I do not plan to change the current behaviour but that should be ok for you. If you want to make an input field optional, you simply make it nullable.

For instance:

public function createFilterWithColor(Filter $filter, ?Filter $nestedRelationFilter = null): Filter
{
    if ($nestedRelationFilter !== null) {
       $filter->addRelationFilters($nestedRelationFilter);
    }
    return $filter;
}

But now that you mention it, there is one thing missing in the issue. I must specify that the @UseInputType annotation can be used in the context of a @Factory and a @Decorate annotations.

from graphqlite.

Ok, there is one last problem I have.
We want to use classes as factory names, so it's easier to navigate through classes which extend input type and we actually found out that it partially works, but only one way. It goes to the factory class, but then it doesn't find an occurence of usage.

Is there a way for Factory, Decorate, UseInputType and ExtendType to be included in class usage?

Btw. is it valid annotation?

class MyFactory
{
  /**
   * @Factory(name=MyFactory::class)
   */
  public function create(int $something): Something;
}

from graphqlite.

Hey @golaod,

We want to use classes as factory names, so it's easier to navigate through classes which extend input type and we actually found out that it partially works, but only one way. It goes to the factory class, but then it doesn't find an occurence of usage.

In this proposal (this is not implemented yet), the "name" of the @Factory annotation represents the GraphQL Input type name.

Names in GraphQL (and input types in this particular class) must follow this Regex: /[_A-Za-z][_0-9A-Za-z]*/

See: https://graphql.github.io/graphql-spec/June2018/#sec-Names

As such, you cannot use "MyFactory::class" as a GraphQL input type name since it contains a "\".

If you want, I could slugify the name passed in parameter though, to make it compatible with the naming regex.

Is there a way for Factory, Decorate, UseInputType and ExtendType to be included in class usage?

I have no way to do this in GraphQLite. This is really an issue that should be opened to the authors of the "PHP Annotations" plugin of PHPStorm: https://github.com/Haehnchen/idea-php-annotation-plugin

from graphqlite.

Ok, the slugification would help

from graphqlite.

👍

from graphqlite.

For the record, instead of UseInputType, I'm going to name the annotation "Parameter".

Usage will be like this:

class PhoneController {
    /**
     * @Query
     * @Parameter(for="$filter", inputType="FilterWithColorInput!")
     */
    public function listPhones(Filter $filter): Grid {
        // ...
    }
}

I'm using the more generic "Parameter" name because in the future, I might reuse this annotation to bundle other annotations attached to the parameter. For instance:

class PhoneController {
    /**
     * @Query
     * @Parameter(for="$filter", inputType="FilterWithColorInput!", annotations={
     *            @Logged,
     *            @Right('CAN_FILTER')
     * })
     */
    public function listPhones(Filter $filter): Grid {
        // ...
    }
}

This will be better (and more performant) than having something like this:

class PhoneController {
    /**
     * @Query
     * @UserInputType(for="$filter", type="FilterWithColorInput!")
     * @LoggedParameter(for="$filter")
     * @RightParameter(for="$filter", name="CAN_FILTER")
     */
    public function listPhones(Filter $filter): Grid {
        // ...
    }
}

Indeed, I will be able to reuse the existing annotations (Logged, Right...) in the context of parameters (instead of the context of a method) and I do not have to do a lookup in the parameters list for each annotation.

from graphqlite.