FeatureServiceProvider #604

Activity

1. zhiyuanliang-ms commented on May 14, 2026

   

   Zhiyuan Liang (zhiyuanliang-ms)

   on May 14, 2026

   Last edited by zhiyuanliang-ms

   Member

   More actions

   Hey, Степан (@Stepami) Thanks for reaching out.

   But it relies on using complicated variants and allocation concepts which might not be needed.

   I can understand that. But if you use Azure App Configuration to create variant feature flags, we offers a wizard UI to create variant feature for you. You won't need to worry about the complicated configurations for variants and allcoations.

   But your feature request seems to be valid, I will bring it to my team.
2. Stepami commented on May 14, 2026

   

   Степан (Stepami)

   on May 14, 2026

   Author

   More actions

   Zhiyuan Liang (@zhiyuanliang-ms) Thanks for the feedback! I use FM without Azure 😅 so main points are:

   • compatibility of the feature-based injection with .NET feature management schema
   • fast-path scenario for simple feature toggles

   The main blocker i see here is lazy feature service instantiation. After that the implementation of FeatureServiceProvider class will be really trivial.
3. zhiyuanliang-ms commented on May 26, 2026

   

   Zhiyuan Liang (zhiyuanliang-ms)

   on May 26, 2026

   Member

   More actions

   Hey, Степан (@Stepami)

   I'd like to clarify the underlying scenario.
   Feature-based DI only makes sense when the enabled/disabled state of the flag can change at runtime. If the flag's state is fixed at startup, you don't need a service provider abstraction at all. The whole point of IVariantServiceProvider<TService> is to re-evaluate on each resolution so that toggling the flag (or its targeting/filters) takes effect without restarting the app.

   I think instead of having a new API WithFeatureService, we can achieve this through default_when_disabled and default_when_enabled variant allocation with the existing WithVariantService API.

   {
         "id": "variantFeatureA",
         "enabled" : true,
         "variants": [
           { "name": "DefaultImpl" },
           { "name": "NewImpl" }
         ],
         "allocation": {
           "default_when_disabled": "DefaultImpl",
           "default_when_enabled": "NewImpl"
         }
       }

   Besides, we want to promote variant feature flag usage, so we don't intentd to introduce a new WithFeatureService that is driven only by feature flag status.
4. Stepami commented on May 26, 2026

   

   Степан (Stepami)

   on May 26, 2026

   Author

   More actions

   Hey, Zhiyuan Liang (@zhiyuanliang-ms)

   The underlying scenario is correct. It's about being able to change the state of the flag at runtime.

   But with addition of .NET feature management schema compatibility

   So instead of this 13 lines of json you provided as example one can use simple "variantFeatureA": true configuration
5. zhiyuanliang-ms commented on May 27, 2026

   

   Zhiyuan Liang (zhiyuanliang-ms)

   on May 27, 2026

   Member

   More actions

   Hey, Степан (@Stepami)

   The underlying scenario is correct. It's about being able to change the state of the flag at runtime.

   So you are not using any feature filter?

   Could you check this PR: #607

   This PR enhance the existing variant service provider and WithVariantService api to achieve the "FeatureServiceProvider`
6. Stepami commented on Jun 4, 2026

   

   Степан (Stepami)

   on Jun 4, 2026

   Author

   More actions

   Still deciding on the design

   • Support keyed service for variant service provider #606 (comment)

   👍React with 👍1Reacted by Zhiyuan Liang

   👀React with 👀1Reacted by Zhiyuan Liang
7. Stepami commented on Jun 6, 2026

   

   Степан (Stepami)

   on Jun 6, 2026

   Author

   More actions

   in addition to #605 (comment)

   it'd be really cool to resolve services by status with context allowing featurefilters and "EnabledFor" stuff:

   public interface IFeatureServiceProvider<TService> where TService : class
   {
        // feature status only
       Task<TService> GetServiceAsync();
   
       // feature filter involved
       Task<TService> GetServiceAsync<TContext>(TContext context);
   }
8. Степан (Stepami)

   closed this as completedon Aug 19, 2026