Split View into BaseView and AsyncView

[Arfey]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Split Django's class based View into dedicated sync and async base classes: a shared BaseView, the existing View for sync, and a new AsyncView for async. The current view_is_async flag and runtime introspection would no longer be needed on the new AsyncView path.

Problem

View tries to cover both sync and async in one class, deciding which mode to use by the view_is_async flag. This leads to several problems:

• A single class with two contracts
• Typing is inaccurate. Signatures collapse into sync/async unions, so type checkers and IDEs cannot give correct hints
• Decorators must branch on view_is_async or iscoroutinefunction at runtime rather than targeting a concrete class
• Third party libraries need markcoroutinefunction to make their wrappers behave correctly

Request or proposal

proposal

Additional Details

• BaseView: holds all shared logic
• View: the sync view, inherits from BaseView (without any backwards-incompatible changes)
• AsyncView: a pure async view, also inherits from BaseView

No impact on existing code, but enables pure async views for new code and a smooth migration path for the old one. Low maintenance cost for the core team (much less than the existing view), and it solves a real problem. I don't see a reason not to do it.

Benefits:

• Clear contract for users: pick sync or async, no flags
• Accurate typing for both sync and async paths
• Cleaner decorator behavior, no runtime branching on async-ness
• Easier for third party libraries
• Removes a class of subtle bugs from mixed sync/async method definitions.

Implementation Suggestions

No response

[github-actions]

Thank you Arfey for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[codingjoe]

Hi @Arfey,

Interesting idea, and I share some frustrations around Django's double async implementation.
That being said, adding another base view in a backwards incompatible change would lead to a lot of complexity for the community, especially for 3rd party packages that need to support multiple Django versions.

Additionally, though I love class-based views, function-based views are still a thing, and they don't suffer from most of the added complexities. So arguably there is a fairly newbie-friendly way to get into both async and sync views using Django.

My hunch is, that you will have a pretty hard time pushing for this change, but maybe there are other ways to address the same problems?

Cheers,
Joe

[Arfey]

@codingjoe The proposal doesn't introduce any backwards-incompatible changes. It just adds a dedicated AsyncView for async-only handlers to simplify life for third-party packages and async users.

[codingjoe]

@codingjoe The proposal doesn't introduce any backwards-incompatible changes. It just adds a dedicated AsyncView for async-only handlers to simplify life for third-party packages and async users.

So you leave the View as is, and you just add an extra AsyncView which has the same but fewer functionalities?

[Arfey]

@codingjoe

• BaseView: holds all shared logic
• View: the sync view, inherits from BaseView (without any backwards-incompatible changes)
• AsyncView: a pure async view, also inherits from BaseView

No impact on existing code, but enables pure async views for new code and a smooth migration path for the old one. Low maintenance cost for the core team (much less than the existing view), and it solves a real problem. I don't see a reason not to do it.

[codingjoe]

I see; good thing we talked about it. In that case, I am fairly indifferent with a slight negative tendency because of the extra complexity (be it minimal).

However, I have a stronger concern about the suggested naming. I know Django historically uses naming abstraction instead of specificity, but that's a trend I'd like to break.

-BaseDog <- Pug
+Dog <- Pug

Following that logic, it would be View, SyncView, AsyncView, which would reintroduce incompatiblity.

[Arfey]

The complexity is already there, it's just pushed out to users and third party libs instead of being solved in core. A few examples:

• Strawberry has to override as_view purely to call markcoroutinefunction so Django picks up that the view is async.
• And the async dispatch override needs a # pyright: ignore because the parent signature is sync, so the override can't be typed honestly.
• The Django docs themselves tell users that if they want method_decorator on dispatch, they have to override dispatch to be async def so the result gets marked as a coroutine. That's a workaround leaking into user code.

It's a very Django way of doing things. See AsyncPaginator, acount, alogin, etc.

[codingjoe]

Hello again,

It's a very Django way of doing things. See AsyncPaginator, acount, alogin, etc.

Yes, there's precedent. And I am not saying dual implementations are bad, but allow me to challenge your reasons, just like with signal handlers.

Strawberry has to override as_view purely to call markcoroutinefunction so Django picks up that the view is async.

Their implementation looks outdated and obsolete. This has been properly handled in Django since version 4.2. Someone should tell'em.

And the async dispatch override needs a # pyright: ignore because the parent signature is sync, so the override can't be typed honestly.

As of now, Django doesn't use types and is unlikely to ever introduce complexity for the sake of type hints. If I recall correctly, @carltongibson warned about arguments like these, and I do share his opinion. Adding complexity to satisfy a type linter is a discussion I'd recommend excluding for this proposal.

The Django docs themselves tell users that if they want method_decorator on dispatch, they have to override dispatch to be async def so the result gets marked as a coroutine. That's a workaround leaking into user code.

Yes, that's because dispatch may return a coroutine but isn't one itself. Which is fine, but the method_decorator only inspects the function, not its return value.

I agree that this isn't great, but it is consistent. If you write an async view, you use async functions. I wouldn't, per se, call this a burden; what people expect dispatch to look like is probably subjective.

Cheers
Joe

[Arfey]

@codingjoe

Their implementation looks outdated and obsolete. This has been properly handled in Django since version 4.2. Someone should tell'em.

In [3]: from strawberry.django.views import AsyncGraphQLView

In [4]: AsyncGraphQLView.view_is_async
Out[4]: False

It's not outdated.

[Arfey]

i think async base middleware is more important

We'll fix it. Step by step @amirreza-sf80, step by step 😌

[codingjoe]

@Arfey they should override view_is_async as well as http_method_names if they don't provide any methods. But I guess it's off-topic.

---

class based view mixins (such as LoginRequired) don't work with async views, and need an alternative

@amirreza-sf80, that's a good point, and since it's not even documented, I'd consider this a bug. I will create a ticket. It's also not too hard to fix.

[codingjoe]

@amirreza-sf80 ticket-37124