asgi.App should not be a sub-class of falcon.App

[davetapley]

This is motivated by #2209 (comment), TLDR:

Because an asgi.App is (in the LSP sense) a falcon.App,
any type for a falcon.App must be 'polluted' with types which only make sense in the ASGI context. E.g.:

The simulate_request methods in testing.client must return Result | StreamedResult,
even though it's not possible to get a StreamedResult with WSGI (aka falcon.App).

That's awkward because StreamedResult doesn't have the very useful text and json methods.

---

I would like to propose moving the shared functionality out of falcon.App and in to a mix-in class.
Then methods like ⬇️ could be extended with a TypeGuard.

falcon/falcon/testing/client.py

Line 2177 in 4910dd7

def _is_asgi_app(app):

and it will be possible to use @overload to correctly narrow to just Result.

I suspect there are other places in the code which would benefit from this (e.g. all the ASGI only websocket code).

Thoughts?

[CaselIT]

Hi,

Please take a look at #2211

[CaselIT]

any type for a falcon.App must be 'polluted' with types which only make sense in the ASGI context. E.g.:

I don't follow, you can surely create a type guard to accept only a subclass. What you can't do is the inverse, you can't create a type guard for the superclass

[davetapley]

Correct! I should have been more explicit:

The 'problem' (with the current implementation) is that if a method needs to accept a ASGI app, and return a different type (if iff app is ASGI), then the method will need to return both types (because you could always replace the WSGI app with the an ASGI app, because LSP).

However: That's not a problem for #2211 because (as I now realize, thanks to your changes 🙏🏻 ) def simulate_request would never return StreamedResult anyway (since there's no way to set _stream_result and _one_shot). Knowing that I'm happy to leave this for now.

[CaselIT]

In a sense yes, but I don't think it's a popular use case to pass the App around to different methods.
In any case it seems that overloads can be used to change the behavior in case it's needed, so it may be good enough for now?