You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to rename EnableClientSideEvaluation to EnableLocalEvaluation for consistency with every other Flagsmith SDK. This is currently impossible without introducing breaking changes:
We do have another constructor with a dedicated configuration object which also has a second HttpClient parameter, for some reason I don't understand, instead of being incorporated into the FlagsmithConfiguration object. Using this constructor is slightly less ergonomic than the previous one, but gives us more flexibility to manipulate the public API for initialising clients:
This constructor is currently only referenced in the "Singleton Initialisation" section on the same docs.
To avoid duplicating parameter documentation and having redundant constructors, we should introduce a new Flagsmith(IFlagsmithConfiguration) constructor, and deprecate all others. Later we can add a Builder pattern to construct clients, which will be backwards compatible with the new single-argument constructor, and is slightly less verbose than manually instantiating a FlagsmithConfiguration object.
The text was updated successfully, but these errors were encountered:
Planning on deprecating IFlagsmithConfiguration as part of this change as well. It's purely a data object with no methods, except for an IsValid method that is not called anywhere, which has no need for an interface.
I want to rename
EnableClientSideEvaluation
toEnableLocalEvaluation
for consistency with every other Flagsmith SDK. This is currently impossible without introducing breaking changes:The
FlagsmithClient
constructor has explicit ordered parameters. We can only add optional parameters at the end, and not rename any existing parameters to avoid breaking changes. This constructor is the main one used in our docs. Customers might be using named parameters, but nothing prevents them from using ordered parameters like we do in our own constructor which exclusively uses ordered parameters.We do have another constructor with a dedicated configuration object which also has a second
HttpClient
parameter, for some reason I don't understand, instead of being incorporated into theFlagsmithConfiguration
object. Using this constructor is slightly less ergonomic than the previous one, but gives us more flexibility to manipulate the public API for initialising clients:This constructor is currently only referenced in the "Singleton Initialisation" section on the same docs.
To avoid duplicating parameter documentation and having redundant constructors, we should introduce a new
Flagsmith(IFlagsmithConfiguration)
constructor, and deprecate all others. Later we can add a Builder pattern to construct clients, which will be backwards compatible with the new single-argument constructor, and is slightly less verbose than manually instantiating aFlagsmithConfiguration
object.The text was updated successfully, but these errors were encountered: