Make AppContext extensible via traits
#777
Conversation
Transition from using the `AppContext` struct internally to using `AppContextTrait` to represent shared global state. This allows end users to implement and extend their own shared application state beyond what loco provides out of the box. The `AppContextTrait` is implemented for `AppContext` so `AppContext` can be used directly by users that don't have a need to extend what is already provided by the context.
|
@mstallmo this looks like a really interesting approach, thanks! I'm wondering how we can give users a pleasant path with all the breaking changes, as there are quite a few (considering AppContext is such a central subject). |
|
@jondot thanks for looking at my PR! I'll go ahead and make the changes to pass CI.
Providing an easy path for users to upgrade has also crossed my mind. As a first step I would be happy to write up a section in the guide and a dedicated blog post detailing how to upgrade an existing app to this new way of implementing Because the existing Another option would be looking into writing a CLI tool or task to make the updates on the user's behalf. I don't have any prior experience in writing a tool like this but would be happy to work on one and take any suggestions the community might have on this topic. |
|
Moving to draft until this pr is ready for review |
Closes #522
This PR changes the
Hookstrait to be generic over theAppContextTraitallowing end users to provide their own structs for application context. This allows for greater flexibility of end users to define the context of their web server as well as makes accessing user defined global application state smoother in various parts of the loco framework.This change is implemented via two traits. The first being the object-safe
Contexttrait and the second being the fullAppContextTrait. The reason behind the split is that tasks and initializers are required to be object-safe and to pass in a generic type, that trait also needs to be object-safe. There are other places where the generic type is required to beCloneand/orDefaultmaking it impossible to implement in one trait. So where object-safety is required theContexttrait is used and everywhere elseAppContextTraitis used.Splitting the implementation into the
Contexttrait andAppContextTraitalso allows for the definition of acreatemethod so the internals of the framework can construct the generic type with minimal disruption to the current code.