Allows selected injected default vars to be merged instead of overwritten

[legrego]

Summary

Currently, injected variables (via injectDefaultVars) allows a variable from one plugin to overwrite a variable of the same name that another plugin provided.

This PR updates the collection of default variables to "flat merge" select variables together, so that properties from one plugin don't clobber variables from another plugin.

This is required to implement the uiCapabilities collection that we discussed.

Example (current functionality):

// Plugin 1
injectDefaultVars() {
	return {
      a: 'plugin 1',
      b: {
         c: 'plugin 1'
      }
	}
}

// Plugin 2
injectDefaultVars() {
	return {
      b: {
         d: 'plugin 2'
      }
	}
}

Results in:

{
  a: 'plugin 1',
  b: {
     d: 'plugin 2'
  }
}

Example (after this PR):

// Plugin 1
injectDefaultVars() {
	return {
      a: 'plugin 1',
      b: {
         c: 'plugin 1'
      }
	}
}

// Plugin 2
injectDefaultVars() {
	return {
      b: {
         d: 'plugin 2'
      }
	}
}

Results in:

{
  a: 'plugin 1',
  b: {
	 c: 'plugin 1',
     d: 'plugin 2'
  }
}

[kobelb]

LGTM - I did a quick audit of our existing default vars, and I'm not seeing any overlap currently that would be relying on the old behavior, and if they wanted to use the old behavior, they can do so using replaceInjectedVars.

[spalger]

I assume we will also want to use defaultDeep() when merging the injectedVars for an app and from the other defaults:

// kibana.js
uiExports: {
  app: {
    // ...
    injectedVars() {
      return {
        uiCapabilities: {
          x: true,
        }
      }
    }
  }
}

// nav_control.js
uiExports: {
  navControl: [ /* ... */ ],
  defaultInjectedVars() {
    return {
      uiCapabilities: {
        y: true,
      }
    }
  }
}

[spalger]

Actually, I take that back, I think we should limit the deep merging to just the uiCapabilities key. We can special case it in ui_render_mixin.js and support deep merging there, in the right order (and maybe even get rid of lodash in this module as a bonus?!). I think there is a decent amount of risk deep merging the injectedVars, and if we just special cased this key we could avoid all that risk.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[kobelb]

Actually, I take that back, I think we should limit the deep merging to just the uiCapabilities key. We can special case it in ui_render_mixin.js and support deep merging there, in the right order (and maybe even get rid of lodash in this module as a bonus?!). I think there is a decent amount of risk deep merging the injectedVars, and if we just special cased this key we could avoid all that risk.

If we're going to handle the uiCapabilities in a special case, should we just do a "flat merge" there as well? So it becomes a barely deep only for uiCapabilities merge?

[spalger]

If we're going to handle the uiCapabilities in a special case, should we just do a "flat merge" there as well?

I'm good with that if it accomplishes what we need

Outdated

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[spalger]

LGTM

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[legrego]

retest

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request