3 ms·
> just stuff everything into a context and provide helper functions for retrieving those variables from the context That doesn't feel in spirit with the use of
by leetrout 4y ago
> just stuff everything into a context and provide helper functions for retrieving those variables from the context
That doesn't feel in spirit with the use of context. I am not saying you are wrong just that it makes me realize I would not have even considered doing something like this.
Have you worked with a library that does this? Curious if this is this more common than I realize?
- SPBS 4y agoYeah, the idiomatic (and fast) chi router does this (https://github.com/go-chi/chi#url-parameters https://github.com/go-chi/chi#url-parameters, https://github.com/go-chi/chi/blob/v1.5.4/context.go#L10 https://github.com/go-chi/chi/blob/v1.5.4/context.go#L10). Routing information in stored within a chi Context (https://github.com/go-chi/chi/blob/c9e87efe9691a63d6a89de8bbd16b04fe4d6640e/context.go#L45 https://github.com/go-chi/chi/blob/c9e87efe9691a63d6a89de8bb...) within the request context, simply because there isn't any other way of transmitting data across http handlers. Echo and Gin have their own Context structs, except instead of http.Request wrapping their Context struct, their Context struct wraps http.Request (thereby rendering it incompatible with the stdlib). It's not a far stretch to have these frameworks retrieve their Context from the http.Request. Instead of // echo Handler func(c *echo.Context) { } they could do // standard Go handler func(w http.ResponseWriter, r *http.Request) { c := echo.GetContext(r) }