Proposal for class-oriented API about strawberry-django HOT 11 CLOSED

I'd propose to drop fields parameter from strawberry_django.field if we decide to go with class-oriented API.

Is anyone against that?

from strawberry-django.

oh, also do we need:

@strawberry_django.query
@strawberry_django.mutation

No we do not need them. I was drafting something, then throw it away and forgot to update. :)

from strawberry-django.

I don't dislike this, my only concert is that might be a bit more confusing than a fields argument (as you'd do on django rest framework and django forms)

the other thing, should consider a way of automatically exposing all the fields? 🤔

/cc @BryceBeagle @jkimbo

from strawberry-django.

oh, also do we need:

@strawberry_django.query
@strawberry_django.mutation

?

it sounds like we could use @strawberry.type directly

from strawberry-django.

Good idea IMO. Easier to read, because user doesnt have to add the fields passed to strawberry_django.type and the declared class fields together to see what fields are available.

Imagine changelog for adding description.
Old api:

@strawberry_django.type(models.User, fields=("id", "name", ))
class User:
    pass

to

@strawberry_django.type(models.User, fields=("name", ))
class User:
    id: strawberry.ID = ...

or new API

@strawberry_django.type(models.User)
class User:
    id: auto
    name: auto

to

@strawberry_django.type(models.User)
class User:
    id: auto = ...
    name: auto

But the pro of the old API is, you can do something like this:

readonly_fields = (...)
update_fields= (...)

@strawberry_django.type(models.User, fields=(*readonly_fields, *update_fields))
class UserType:
   pass
   
@strawberry_django.input(models.User, fields=update_fields)
class UserUpdate:
   pass
       

from strawberry-django.

But the pro of the old API is, you can do something like this:

readonly_fields = (...)
update_fields= (...)

@strawberry_django.type(models.User, fields=(*readonly_fields, *update_fields))
class UserType:
   pass
   
@strawberry_django.input(models.User, fields=update_fields)
class UserUpdate:
   pass

You can generate dataclasses like this

dataclasses.make_dataclass('UserUpdate', fields)

Or use class inheritance

class ReadOnlyFields:
    ...
class UpdateFields:
    ...

@strawberry_django.type(models.User)
class UserType(ReadOnlyFields, UpdateFields):
    pass
    
@strawberry_django.input(models.User)
class UserType(UpdateFields):
    pass

from strawberry-django.

We are currently working on that. Code is still under development but it's already available in https://github.com/strawberry-graphql/strawberry-graphql-django/tree/feature/class-api branch if someone wants to take a look or try it :)

from strawberry-django.

https://www.python.org/dev/peps/pep-0647/ has the notion of type guards. Getting this done via static type checkers seems preferable over writing validators.

Having said that it's not clear that the PEP above has enough to specify all the constraints needed.

from strawberry-django.

https://www.python.org/dev/peps/pep-0647/ has the notion of type guards. Getting this done via static type checkers seems preferable over writing validators.

Having said that it's not clear that the PEP above has enough to specify all the constraints needed.

Do you have example how this could be used with class oriented API?

from strawberry-django.

It's not clear that this feature is usable by end users just yet. It seems to be designed for type checkers like mypy/pyright. Someone on python discord was speculating about implementing refinement types using TypeGuards.

The specific example discussed was:

from dataclasses import dataclass
from typing import Any, Optional, TypeGuard

class LessThan10(float):
    pass

def is_LessThan10(x: float) -> TypeGuard[LessThan10]:
    return x < 10.0

@dataclass
class Thing:
    x: LessThan10
    y: float

I would like a type checker to be able to detect that Thing(20, 1) is a type error.

@erictraut would know, but I'm not sure if I can tag him here.

from strawberry-django.

This will be part of v0.2 release. See pull request #30. Let's continue discussion there.

from strawberry-django.