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
Remove all Sanic reliance upon ctx values in the routing module.
Rationale
There are several locations throughout Sanic where the developer is provided with a ctx object to inject arbitrary values. The two most visible locations are Sanic.ctx and Request.ctx. However, this also exists for the router, routes, blueprints, and connections.
Only in routing does Sanic actually use the object for storing internal state. It will be much more consistent if Sanic never touches these objects, and therefore they can serve their original purpose: injection of arbitrary values without the worry of conflict.
Implementation
The reason that Sanic has used these values is so that sanic-routing can exist independently of sanic. So, from the perspective of sanic-routing, these objects are fulfilling their purpose and not being overburdened with values. Ultimately, however, this is somewhat moot as far as the developer is concerned as they need to be careful not to overwrite these values.
Therefore, the simplest approach is probably to add a state object into sanic-routing that looks and functions the same was as ctx, but is specifically intended for arbitrary "stateful" information coming from Sanic.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions.
TLDR
Remove all Sanic reliance upon
ctx
values in therouting
module.Rationale
There are several locations throughout Sanic where the developer is provided with a
ctx
object to inject arbitrary values. The two most visible locations areSanic.ctx
andRequest.ctx
. However, this also exists for the router, routes, blueprints, and connections.Only in routing does Sanic actually use the object for storing internal state. It will be much more consistent if Sanic never touches these objects, and therefore they can serve their original purpose: injection of arbitrary values without the worry of conflict.
Implementation
The reason that Sanic has used these values is so that
sanic-routing
can exist independently ofsanic
. So, from the perspective ofsanic-routing
, these objects are fulfilling their purpose and not being overburdened with values. Ultimately, however, this is somewhat moot as far as the developer is concerned as they need to be careful not to overwrite these values.Therefore, the simplest approach is probably to add a
state
object intosanic-routing
that looks and functions the same was asctx
, but is specifically intended for arbitrary "stateful" information coming fromSanic
.See #2300 and #2302
The text was updated successfully, but these errors were encountered: