The @plateshift.repository.service.feature_flag
-service is used for internal handling but is publicly available.
Using the @plateshift.feature_flag.repository
-service is the recommended way. This "Wrapper" has some extra logic like
and is taking care of response-tagging and scope-resolution falling back to the next scope in succession until a defined
state is found or the configured default-value is used.
/** @var PlateShift\FeatureFlagBundle\API\FeatureFlagRepository $featureFlagRepository */
$featureFlagRepository->isEnabled('foo_feature');
$featureFlagRepository->isDisabled('bar_feature');
Functions to check a feature in twig
are available.
{% if is_feature_enabled('foo_feature') %}
feature is enabled
{% endif %}
{% if is_feature_disabled('bar_feature') %}
feature is disabled
{% endif %}
Features can be exposed to a javascript-friendly context using either json, javascript or data-attributes.
Note: All of those functions export the result unescaped.
You can expose the features in a simple json format.
{{ expose_features_json() }}
This will result in an json-string containing an object with identifiers as keys and one boolean
attribute "enabled
".
{"feature_foo": {"enabled": true}, "feature_bar": {"enabled": false}}
Will output data-attributes to use on dom-elements.
<body {{ expose_features_data_attributes() }}>
This will result in the following html-snippet:
<body data-feature-foo="true" data-feature-bar="false">
Note that the _
will be replaced by -
. Javascript-side access will be body.dataset.featureFoo
.
Exposing to javascript will use the json-function to assign the value to a window-attribute.
Exposure in "window.ipFeatures":
{{ expose_features_javascript() }}
Or with adjusted key in the window object (will write the states to "window.features"):
{{ expose_features_javascript('features') }}
The javascript can be adjusted by overriding @ibexadesign/feature_flag/expose/javascript.html.twig
.