Custom FeatureDefinitionProvider still depends on IConfiguration

[pardahlman]

I've been look at the latest pre-release of this package (2.2.0-preview) - it is a great improvement in terms of migration from other feature management system 👍

However, when implementing a custom IFeatureDefinitionProvider I noticed that FeatureFilterConfiguration still expects its data to be modeled as IConfiguration. There are a few reasons why I think this is problematic:

• Non-transparent API. It is not transparent what settings are mandatory or even expected, IConfiguration is very broad.
• Cumbersome API. In my case, I have loaded feature toggle data that I want to map to percentage filter, groups etc. The best way I have found is to look at the source code for the filter classes and mimic the expected configuration in an in-memory configuration collection.
• Surprising API. Configuration is a concept that is tied to application startup. Whenever code is reliant on configuration, the first step is usually to map it the configuration to a strongly typed class and let downstream classes rely on it.

It would be great if the API for implementing a custom data source/adapter for the feature management system would be strongly typed and not reliant on IConfiguration.

[jimmyca15]

Thank you for the feedback @pardahlman . I can see why you have listed these points. We chose to stick with IConfiguration for two main reasons. First, the library is designed by default around pulling feature flags from configuration. Secondly, the feature filter parameters are the configuration for an individual instance of a feature filter.

We will discuss how we can improve this and see if the requirement to use IConfiguration can be laxed in favor of another way to specify feature filter parameters. This will not make it into 2.2.0 as we have already started the process of promoting 2.2.0-preview.

[DovPet]

Hi, I don't know where I have to write this, but it is very unclear how to create CustomFeatureDefinitionProvider and choose my provider to be database not appsettings.json file. In documentation it is mentioned, but it is fuzzy how to use it in code. I think, just a simple example of database implementation would be very great .

[jimmyca15]

Hello @DovPet we can look into adding an example like that. For the time being though, we do have this test that uses an in-memory feature definition provider. It should provide a starting point, the only difference would be that your features would come from a database instead of in-memory.

[jimmyca15]

Given IConfiguration is not some strong type that hints at the underlying configuration exposed, it is no more useful than object. As such, I think we can add a new object property on FeatureFilterConfiguration that custom feature definition providers can populate rather than the existing Parameters property.

Feature filters should check for both.

[jimmyca15]

This has been addressed in version 4.5.0

release notes