View Source Unleash (Unleash v1.14.0)
If you have no plans on extending the client, then Unleash will be the main
usage point of the library. Upon starting your app, the client is registered
with the unleash server, and two GenServers are started, one to fetch and
poll for feature flags from the server, and one to send metrics.
Configuring :disable_client to true disables both servers as well as
registration, while configuring :disable_metrics to true disables only
the metrics GenServer.
Summary
Types
The Unleash Context, mostly used to evaluate conditional activation strategies. https://docs.getunleash.io/reference/unleash-context.
Represents local feature overrides that can be used to force a feature evaluation value, bypassing its activation strategies.
Functions
Checks if the given feature is enabled. Checks as though an empty context was passed in.
Checks if the given feature is enabled.
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.
Returns a variant for the given name.
Aliased to enabled?/2
Types
@type context() :: %{ optional(:app_name) => String.t(), optional(:environment) => String.t(), optional(:user_id) => String.t(), optional(:session_id) => String.t(), optional(:remote_address) => String.t(), optional(:properties) => %{required(atom() | String.t()) => String.t()}, optional(:current_time) => String.t() }
The Unleash Context, mostly used to evaluate conditional activation strategies. https://docs.getunleash.io/reference/unleash-context.
Custom context properties can be defined in the :properties field.
Note that, for hystorical / backwards-compatibility reasons,
both atom and string keys are allowed in the properties map.
You are encouraged to use find_in_context/2 to lookup context values in a way
that handles fallback to properties and the different style of keys correctly.
Represents local feature overrides that can be used to force a feature evaluation value, bypassing its activation strategies.
These can be inherited from the clients, see Unleash.Propagation.Plugs
Functions
Checks if the given feature is enabled. Checks as though an empty context was passed in.
Examples
iex> Unleash.enabled?(:my_feature, false)
false
iex> Unleash.enabled?(:my_feature, true)
trueChecks if the given feature is enabled.
If :disable_client is true, simply returns the given default.
If :disable_metrics is true, nothing is logged about the given toggle.
Examples
iex> Unleash.enabled?(:my_feature)
false
iex> Unleash.enabled?(:my_feature, context)
false
iex> Unleash.enabled?(:my_feature, context, true)
falseLooks 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:
- 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.
- 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 a variant for the given name.
If :disable_client is true, returns the fallback.
A variant
allows for more complicated toggling than a simple true/false, instead
returning one of the configured variants depending on whether or not there
are any overrides for a given context value as well as factoring in the
weights for the various weight options.
Examples
iex> Unleash.get_variant(:test)
%{enabled: true, name: "test", payload: %{...}}
iex> Unleash.get_variant(:test)
%{enabled: false, name: "disabled"}Aliased to enabled?/2
Aliased to enabled?/3