Checks if the given feature is enabled.

Takes a feature name and a set of extra parameters (in the form of a keyword list) that customise the behaviour of the feature check, see enabled_opt/0 for the supported parameters and their defaults.

Returns a boolean indicating whether the feature flag is enabled. Can return nil only if :fallback was set to nil and the feature was not found locally.

Examples

iex> Unleash.enabled?(:flag_a)
iex> Unleash.enabled?(:flag_b, context: get_context(), fallback: true, allow_overrides: false)

Compile-time option keys only

Whenever you call Unleash.enabled/2, option keys must be provided statically at compile-time, similar to how you would use function call syntax. The compiler will raise an error when that's not the case.

This requirement does not extend to the feature name or option values, which can be dynamic runtime terms. However, for the sake of readability and clarity regarding which/how feature flags are being checked, it is recommended to also provide those statically whenever possible, particularly for feature names.

For instance, rather than writing:

iex> opts = [allow_overrides: true, fallback: true]
...> {name, opts} = case some_condition do
...>   true -> {:flag1, Keyword.put(opts, :context, %{user_id: "u-42"})}
...>   false -> {:flag2, opts}
...> end
...> Unleash.enabled?(name, opts)

You should write:

iex> case some_condition do
...>   true -> Unleash.enabled?(:flag1, allow_overrides: true, fallback: true, context: %{user_id: "u-42"})
...>   false -> Unleash.enabled?(:flag2, allow_overrides: true, fallback: true)
...> end

In the second example, it is much clearer to see which feature flags are being checked and the parameters being used.

If you absolutely need to pass the options using arbitrary runtime expressions (which is extremely unlikely), you can use runtime_enabled?/2, but its usage is discouraged.

@spec find_in_context(context(), atom() | String.t()) :: term()

Looks for a context value, taking care of some of the nasty details like fallback to :properties (a.k.a. custom context values) with support for both atom and string keys.

Specifically:

1. If the key is a standard context key (either in its atom or string form), it looks for it in the standard context fields, without fallbacking to properties.
2. Otherwise, it looks for it in properties, trying both the atomized and the stringified version of the key, starting from the supplied one.

NOTE that this can create atom at runtimes, which is dangerous. It is highly recommended you do not call this function with values from untrusted / unbounded sources.

Returns the variant for the given feature flag.

See https://unleash.github.io/docs/beta_features#feature-toggle-variants

Takes a feature name and a set of options (in the form of a keyword list) that customise the behaviour of the feature check, see get_variant_opt/0 for the supported options and their defaults. The same constraints on options as enabled/2 apply, see its doc.

A special variant %{enabled: false, name: "disabled"} will be returned in any of these scenarios:

• the feature flag is disabled
• the feature flag does not define any variants
• the feature flag does not exist and no fallback has been supplied

Examples

iex> Unleash.get_variant(:feature_a)
iex> Unleash.get_variant(:test, fallback: %{enabled: true, name: "variant_two"})

@spec runtime_enabled?(feature_name(), [enabled_opt()]) :: boolean() | nil

Runtime-friendly version of enabled?/2 with support for runtime option keys.

You are encouraged to use enabled?/2 whenever possible. Check its doc for more info.

@spec runtime_get_variant(feature_name(), get_variant_params()) ::
  Unleash.Variant.result() | nil

Runtime-friendly version of get_variant/2 with support for runtime option keys.

You are encouraged to use get_variant/2 whenever possible. Check its doc for more info.

Starts the Unleash SDK.

See Unleash for details.