Commit f60317f4 authored by Rémy Coutable's avatar Rémy Coutable

Merge branch 'frontend-feature-flags' into 'master'

Support pushing of feature flags to the frontend

Closes gitlab-org/release/framework#17

See merge request gitlab-org/gitlab-ce!22197
parents a8513c7d 21940d1e
...@@ -69,6 +69,37 @@ For more information about rolling out changes using feature flags, refer to the ...@@ -69,6 +69,37 @@ For more information about rolling out changes using feature flags, refer to the
[Rolling out changes using feature flags](rolling_out_changes_using_feature_flags.md) [Rolling out changes using feature flags](rolling_out_changes_using_feature_flags.md)
guide. guide.
### Frontend
For frontend code you can use the method `push_frontend_feature_flag`, which is
available to all controllers that inherit from `ApplicationController`. Using
this method you can expose the state of a feature flag as follows:
```ruby
before_action do
push_frontend_feature_flag(:vim_bindings)
end
def index
# ...
end
def edit
# ...
end
```
You can then check for the state of the feature flag in JavaScript as follows:
```javascript
if ( gon.features.vimBindings ) {
// ...
}
```
The name of the feature flag in JavaScript will always be camelCased, meaning
that checking for `gon.features.vim_bindings` would not work.
### Specs ### Specs
In the test environment `Feature.enabled?` is stubbed to always respond to `true`, In the test environment `Feature.enabled?` is stubbed to always respond to `true`,
......
...@@ -30,5 +30,20 @@ module Gitlab ...@@ -30,5 +30,20 @@ module Gitlab
gon.current_user_avatar_url = current_user.avatar_url gon.current_user_avatar_url = current_user.avatar_url
end end
end end
# Exposes the state of a feature flag to the frontend code.
#
# name - The name of the feature flag, e.g. `my_feature`.
# args - Any additional arguments to pass to `Feature.enabled?`. This allows
# you to check if a flag is enabled for a particular user.
def push_frontend_feature_flag(name, *args)
var_name = name.to_s.camelize(:lower)
enabled = Feature.enabled?(name, *args)
# Here the `true` argument signals gon that the value should be merged
# into any existing ones, instead of overwriting them. This allows you to
# use this method to push multiple feature flags.
gon.push({ features: { var_name => enabled } }, true)
end
end end
end end
# frozen_string_literal: true
require 'spec_helper'
describe Gitlab::GonHelper do
let(:helper) do
Class.new do
include Gitlab::GonHelper
end.new
end
describe '#push_frontend_feature_flag' do
it 'pushes a feature flag to the frontend' do
gon = instance_double('gon')
allow(helper)
.to receive(:gon)
.and_return(gon)
expect(Feature)
.to receive(:enabled?)
.with(:my_feature_flag, 10)
.and_return(true)
expect(gon)
.to receive(:push)
.with({ features: { 'myFeatureFlag' => true } }, true)
helper.push_frontend_feature_flag(:my_feature_flag, 10)
end
end
end
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment