You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello everyone. Currently in DRF there are 2 types of class-based views ApiView and ViewSet. ApiView cannot implement multiple methods that will handle multiple paths. This problem is partially solved by ViewSet, but it also has problems. Inconvenient comparison with http methods, a lot of implicit magic. Also, if some ViewSet methods require some specific classes parsers/renderers/permissions... then this turns into an unreadable combiner. I have an idea and sketched code to implement a new View. What it will roughly look like.
urlpatterns = [
*router(base_path='api/v1/users/, User),
]
And we get
urlpatterns = [
URLPattern(path='api/v1/users/', ...),
URLPattern(path='api/v1/users/<int:pk>/', ...),
URLPattern(path='api/v1/users/<int:pk>/change_password', ...),
]
With this implementation, it is more convenient to write a View with a large number of methods and everything looks more explicit. Decorators are for convenience and in Runtime they will be removed and all dependencies will go into the class. They can also be extended with various dependencies as in FastApi.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello everyone. Currently in DRF there are 2 types of class-based views
ApiView
andViewSet
.ApiView
cannot implement multiple methods that will handle multiple paths. This problem is partially solved byViewSet
, but it also has problems. Inconvenient comparison with http methods, a lot of implicit magic. Also, if some ViewSet methods require some specific classes parsers/renderers/permissions... then this turns into an unreadable combiner. I have an idea and sketched code to implement a new View. What it will roughly look like.In ../urls.py
With this implementation, it is more convenient to write a View with a large number of methods and everything looks more explicit. Decorators are for convenience and in Runtime they will be removed and all dependencies will go into the class. They can also be extended with various dependencies as in
FastApi
.Beta Was this translation helpful? Give feedback.
All reactions