Use it to pass connection/request-scoped values: that is, values that could only exist once you have a request. authentication tokens, user details, connection IDs: things that can't be known/generated before the connection has been received.
e.g. gorilla/mux (https://github.com/gorilla/mux) uses it to pass route-matching information back to the user (i.e. for /user/:name, the :name value). Don't use context to pass app-level dependencies, as it makes testing, reasoning and debugging hard. On Thursday, July 7, 2016 at 4:03:18 PM UTC-7, Tyler Compton wrote: > > I'm really excited to see context.Context become a first class citizen in > Go 1.7. After using context, it feels like a natural way to write Go > network code and it fits naturally in the standard library. I'm trying to > figure out how I can improve existing code with the new features that come > with it. > > In Go 1.7, requests now can contain a context, and the context can be > changed. This seems really cool, but I don't know what exactly I can do > that I can't do before, other than what the documentation specifically > outlines: "For outgoing client requests, the context controls cancelation." > > Is there anything else we will be able to do that I should be looking > into? What are your plans? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
