Enhancement: Serialization context

[alg]

Is your feature request related to a problem? Please describe.

While working on implicit PK serialization I noticed that serialize method in model views accepts the raw Request object. This couples the serialization functionality with the infrastructure code. The reasons this might not be a good thing are:

• There's no clear separation between infrastructure code and the logic of serialization. The fact that serialization depends on the specific implementation of Request in an external library makes it very fragile. Should Starlette decide to change it, all serialization logic (in this library or in the user-space overrides) may start failing.

• Request is actually the context, it's just not wrapped in it, and so adding more parameters to the context is troublesome. I the action was pushed into request.state.action for the same reason as it became mundane to provide the request and the action separately as arguments to many methods. Imagine, you need to extend the context with the third and fourth. It may quickly get out of hand.

• As a side-effect, testing of the serialization logic is currently involves making fake requests to the Starlette test client. It's slower than it should and it's hard to setup (you need to configure the client and place records in the database -- for UUID PKs we needed an extra Uuid type implemented specifically for testing). The code of the actual test sinks in the preparations and not very clear and expressive.

I would like to initiate the discussion of this.

Describe the solution you'd like

I'd like to discuss providing required parts of Request through some serialization context object. This object may, for example, contain the action (LIST, EDIT etc), some request details (headers or query params) that may affect the serialization of a field and the url_for method that delegates the actual logic to the incapsulated request object. In other words, we could add the layer of abstraction that would screen the serialization logic from the actual request.

In tests, this context would initialize directly with all necessary data. While in production, it would use the request from Starlette.

What do you think? If you are interested, I may find time during the next few days to work on a quick draft to illustrate the idea.

I may be talking nonsense to you here. Feel free to tell me that. ))