1 files changed, 61 insertions, 55 deletions
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index c5a1d915be6..cca52706ddc 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -446,6 +446,19 @@ The disadvantage of this:
   port `render_if_exists` to CE.
 - If we have typos in the partial name, it would be silently ignored.
 
+
+##### Caveats
+
+The `render_if_exists` view path argument must be relative to `app/views/` and `ee/app/views`.
+Resolving an EE template path that is relative to the CE view path will not work.
+
+```haml
+- # app/views/projects/index.html.haml
+
+= render_if_exists 'button' # Will not render `ee/app/views/projects/_button` and will quietly fail
+= render_if_exists 'projects/button' # Will render `ee/app/views/projects/_button`
+```
+
 #### Using `render_ce`
 
 For `render` and `render_if_exists`, they search for the EE partial first,
@@ -535,40 +548,56 @@ due to `prepend`, but Grape is complex internally and we couldn't easily do
 that, so we'll follow regular object-oriented practices that we define the
 interface first here.
 
-For example, suppose we have a few more optional params for EE, given this CE
-API code:
+For example, suppose we have a few more optional params for EE. We can move the
+params out of the `Grape::API` class to a helper module, so we can `prepend` it
+before it would be used in the class.
 
 ```ruby
 module API
-  class MergeRequests < Grape::API
-    # EE::API::MergeRequests would override the following helpers
-    helpers do
-      params :optional_params_ee do
+  class Projects < Grape::API
+    helpers Helpers::ProjectsHelpers
+  end
+end
+```
+
+Given this CE API `params`:
+
+```ruby
+module API
+  module Helpers
+    module ProjectsHelpers
+      extend ActiveSupport::Concern
+      extend Grape::API::Helpers
+
+      params :optional_project_params_ce do
+        # CE specific params go here...
       end
-    end
 
-    params :optional_params do
-      # CE specific params go here...
+      params :optional_project_params_ee do
+      end
 
-      use :optional_params_ee
+      params :optional_project_params do
+        use :optional_project_params_ce
+        use :optional_project_params_ee
+      end
     end
   end
 end
 
-API::MergeRequests.prepend(EE::API::MergeRequests)
+API::Helpers::ProjectsHelpers.prepend(EE::API::Helpers::ProjectsHelpers)
 ```
 
-And then we could override it in EE module:
+We could override it in EE module:
 
 ```ruby
 module EE
   module API
-    module MergeRequests
-      extend ActiveSupport::Concern
+    module Helpers
+      module ProjectsHelpers
+        extend ActiveSupport::Concern
 
-      prepended do
-        helpers do
-          params :optional_params_ee do
+        prepended do
+          params :optional_project_params_ee do
             # EE specific params go here...
           end
         end
@@ -578,9 +607,6 @@ module EE
 end
 ```
 
-This way, the only difference between CE and EE for that API file would be
-`prepend EE::API::MergeRequests`.
-
 #### EE helpers
 
 To make it easy for an EE module to override the CE helpers, we need to define
@@ -880,7 +906,7 @@ import bundle from 'ee/protected_branches/protected_branches_bundle.js';
 import bundle from 'ee_else_ce/protected_branches/protected_branches_bundle.js';
 ```
 
-See the frontend guide [performance section](./fe_guide/performance.md) for
+See the frontend guide [performance section](fe_guide/performance.md) for
 information on managing page-specific javascript within EE.
 
 
@@ -888,7 +914,7 @@ information on managing page-specific javascript within EE.
 ### script tag
 
 #### Child Component only used in EE
-To seperate Vue template differences we should [async import the components](https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components).
+To separate Vue template differences we should [async import the components](https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components).
 
 Doing this allows for us to load the correct component in EE whilst in CE
 we can load a empty component that renders nothing. This code **should**
@@ -911,7 +937,7 @@ export default {
 ```
 
 #### For JS code that is EE only, like props, computed properties, methods, etc, we will keep the current approach
- - Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](https://docs.gitlab.com/ee/development/ee_features.html#javascript-code-in-assetsjavascripts) alias we already have for webpack.
+ - Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) alias we already have for webpack.
   - This means all the EE specific props, computed properties, methods, etc that are EE only should be in a mixin in the `ee/` folder and we need to create a CE counterpart of the mixin
 
 ##### Example:
@@ -922,7 +948,7 @@ import mixin from 'ee_else_ce/path/mixin';
     mixins: [mixin]
 }
 ```
-  
+
 - Computed Properties/methods and getters only used in the child import still need a counterpart in CE
 
 - For store modules, we will need a CE counterpart too.
@@ -933,47 +959,27 @@ import mixin from 'ee_else_ce/path/mixin';
   - Since we are using the async loading to check which component to load, we'd still use the component's name, check [this example](#child-component-only-used-in-ee).
 
 * **EE extra HTML**
-  - For the templates that have extra HTML in EE we will use the `ifEE` mixin with the `v-if` directive.
-  - You can either use the `template` tag as a wrapper or directly in the element, if there is only one element to be rendered in EE:
-
-```html
-  <template v-if="ifEE">
-    <p>Several</p>
-    <p>non wrapper</p>
-    <p>elements</p>
-    <p>that are rendered</p>
-    <p>in EE only</p>
-  </template>
-```
-
-
-```html
-  <ul v-if="ifEE">
-    <li>One wrapped</li>
-    <li>element</li>
-    <li>that is rendered</li>
-    <li>in EE only</li>
-  </template>
-```
+  - For the templates that have extra HTML in EE we should move it into a new component and use the `ee_else_ce` dynamic import
 
 ### Non Vue Files
 For regular JS files, the approach is similar.
 
-1. We will keep using the [`ee_else_ce`](https://docs.gitlab.com/ee/development/ee_features.html#javascript-code-in-assetsjavascripts) helper, this means that EE only code should be inside the `ee/` folder.
+1. We will keep using the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) helper, this means that EE only code should be inside the `ee/` folder.
   1. An EE file should be created with the EE only code, and it should extend the CE counterpart.
-1. For code inside functions that can't be extended, we will use an `if` statement with the `ifEE` helper
+  1. For code inside functions that can't be extended, the code should be moved into a new file and we should use `ee_else_ce` helper:
 
 ##### Example:
 
 ```javascript
-import { ifEE } from '~/lib/utils/common_utils'
-if (ifEE) {
-  $('.js-import-git-toggle-button').on('click', () => {
-    const $projectMirror = $('#project_mirror');
+  import eeCode from 'ee_else_ce/ee_code';
 
-    $projectMirror.attr('disabled', !$projectMirror.attr('disabled'));
-  });
-}
+  function test() {
+    const test = 'a';
+
+    eeCode();
+
+    return test;
+  }
 ```
 
 ## SCSS code in `assets/stylesheets`