Change procedural API for adding functions to fields to `add_field`/`add_source` about ariadne HOT 8 CLOSED

Perhaps scalars could accept everything directly in the class initializer?

from ariadne.

For API consistency we should also update the Enum implementation to let you create enum via set_items perhaps.

from ariadne.

Shouldn't the enum also accept all of its attributes in the constructor? Compare:

foo = Enum("Foo")
foo.set_items(something)

# vs.

foo = Enum("Foo", something)

from ariadne.

Slightly related: should we warn if you try to set items/resolver/source/whatever of the same type for a second time using the same bindable instance?

from ariadne.

Shouldn't the enum also accept all of its attributes in the constructor? Compar

This is correct, and its already the case with our Enums.

Likely we should update Scalar to accept three kwargs in addition to decorators.

The question is if there are scenarios out there for using procedural API for setting scalar resolvers, ergo:

foo = Scalar("test")
foo.set_serializer(my_serializer)

This looks good on the surface, but what possible uses are there for it?

Slightly related: should we warn if you try to set items/resolver/source/whatever of the same type for a second time using the same bindable instance?

Yup, missing the resolver on field can lead to tricky bugs. We should signalize to the dev if such situations happen.

from ariadne.

I've decided to sit down and put together the draft for API change:

ResolverMap

foo = ResolverMap("Name")


# decorator syntax
@foo.field("name")
def resolve_name(*_):
    ...


# setter syntax
foo.set_alias("name", "attr_name")
foo.set_field("name", resolve_name)
foo.set_source("name", observe_name)

Scalar

Decorator syntax:

foo = Scalar("Name")


@foo.serializer
def serialize_foo(*_):
    ...


@foo.value_parser
def parse_foo_value(*_):
    ...


@foo.literal_parser
def parse_foo_literal(*_):
    ...

Constructor syntax:

foo = Scalar(
    "Name",
    serializer=serialize_foo,
    value_parser=parse=parse_foo_value,
    literal_parser=parse_foo_literal,
)

Perhaps we should rollback to GraphQL's serialize, parse_value and parse_literal for constructor kwargs?

Enum

foo = Enum("Name", enum_or_dict)

Union

Constructor syntax:

foo = Union("Name", type_resolver)

Decorator syntax:

foo = Union("Name")


@foo.type_resolver
def resolve_union_type(*_):
    ...

from ariadne.

For what it's worth, I would be strongly in favor of the constructor-only API.

Procedural APIs may seem convenient, but my experience is that by empowering any code that has a reference to an object to modify it, developers are often tempted into difficult-to-follow code patterns.

from ariadne.

We could work around what you are mentioning by raising warning or error when user changes previously set resolver. We already have some of those in place - our bindables already raise ValueError if name is not found in schema, or types don't match.

from ariadne.