Should Router be a subclass of Starlette? about starlette HOT 3 CLOSED

Thank you @tomchristie -- just a brief addition. I have actually expressed this wrong, as by "subclass" I was actually thinking of a "subtype", i.e. -- exactly as you said -- that it would be useful if all ASGI apps in Starlette (routes, endpoints etc) shared the same interface. Perhaps that can be formalised in the form of some kind of ABC or mixin or something similar. Thank you for the great work!

from starlette.

I was wondering something similar or maybe when we instantiate Starlette we can set the router attribute as well, like we are doing with the debug attribute, but I am.not sure. What do you think guys?

from starlette.

Would it make sense to make Router a subclass of Starlette

Not really, the Router class is a subset of the features that Starlette class offers.
If you want to mount a

What we should do tho, is make sure that router and app share the same fundamental API for routing. First pass on that means that stuff like this ought to just work.

app = Router()

@app.route('/')
async def homepage(...):
    ...

It's possible that we should hide away the lower-level Path interface (at least at this point), or else find a clean way to expose the same thing in Starlette, so that the two interfaces match.

Once we've got two properly matching interfaces, then it's clearer.

It's also worth highlighting that you can submount Starlette instances onto a parent, too. That's what you need to do if you want to have a submounted set of functionality that also handles eg. lifespan, or custom exception handling.

from starlette.