Open jimmyca15 opened 6 months ago
I like it. I was thinking about something similar too.
The TargetingHttpContextMiddleware
is only useful for ASP.NET targeting telemetry. The name of UseFeatureManagement
is quite generic. We may want to reserve that name for a more base library though.
The middleware is defined in our base ASP.NET Core library, given the extension depends on ASP.NET core, I don't think it could go into any more base of a library.
You are right about the base library, Jimmy.
As we discussed offline, since TargetingHttpContextMiddleware
is only useful for 1. targeting scenarios 2. AppInsights telemetry. To be a good citizen, ideally, we can add middleware only when we detect those conditions. Then I have no concerns to wrap the middleware in the generic method UseFeatureManagement
.
I think this middleware can be obsoleted by a TargetingContextAccessor doing the same thing. I spoke a little with Jimmy about the idea. I plan to make a PR and we can discuss further on that. Happy to keep this issue open until that's decided on.
If I understand your proposal correctly, the problem with it is that the request that calls TrackEvent may never trigger a feature evaluation at all. The heart-vote button is an example. If I misunderstand your proposal, please elaborate.
On the other hand, I'm happy to ship an in-box HttpContext-based TargetingContextAccessor. Please open a separate issue with details of the proposal.
Hey @zhenlan & @jimmyca15 , looks like we were considering to add ASP.NET stuff to the .AddFeatureManagement()
. Do we still feel that way about the out-of-the-box HttpTargetingContextAccessor?
add ASP.NET stuff to the .AddFeatureManagement()
Adding anything ASP.NET related to the AddFeatureManagement
method isn't doable since AddFeatureManagement
is in the base feature management library.
Expected
Actual
See here.