Add ContextService

[joshdover]

Summary

This adds a generic implementation for leveraging the Handler Context pattern.

This is a slightly updated version of the service proposed by #40554

Basic Example

interface MountContext {}
type MountArgs = [HTMLElement];
type MountReturn = () => void;

interface App {
  mount: (context: MountContext, ...mountArgs: MountArgs) => MountReturn
}

Setting up a ContextContainer and configuring handlers

export class ApplicationService {
  private readonly apps$ = new BehaviorSubject<App[]>([]);

  public setup({ context }) {
    this.mountContext = context.createContextContainer<
      MountContext,
      MountArgs,
      MountReturn
    >();
    return {
      registerApp: (plugin: symbol, app: App) =>
        this.apps$.next([
          ...this.apps$.value,
         {
           ...app,
           mount: this.mountContext.createHandler(plugin, app.mount)
         }
      ]),
      registerContext: this.mountContext.registerContext
    };
  }

  public async start() { ... }
}

Invoking a configured handler

export class ApplicationService {
  private readonly apps$ = new BehaviorSubject<App[]>([]);

  public setup() { ... }

  public async start({ context }) {
    const mountContext = context.createContextContainer<ApplicationContext>();
    
    // dumb example of mounting an app
    const appToMount = this.apps$.value[0];
    // `appToMount.mount` will automatically invoke each context provider and
    // call the original mount function with it
    const unmount = appToMount.mount(document.createElement('div'));

    return {
      registerContext: mountContext.registerContext
    };
  }
}

Details

This approach does leak details about consuming plugins to context service owners via the plugin argument that must be passed. We evaluated a few approaches and have decided that this had the least-bad consequences. If we decide that this level of detail is dangerous, we could go a step further and use some sort of opaque identifier such as a symbol generated by Core for each plugin.

To do in future PRs:

• Add a parallel service to the server-side

Dev Docs

New Platform plugins may now implement their own context API on the server or client.

A IContextContainer can be used by any Core service or plugin (known as the "service owner") which wishes to expose APIs in a handler function. The container object will manage registering context providers and configuring a handler with all of the contexts that should be exposed to the handler's plugin. This is dependent on the dependencies that the handler's plugin declares.

class MyPlugin {
  private readonly handlers = new Map();
  setup(core) {
    this.contextContainer = core.context.createContextContainer();
    return {
      registerContext(pluginOpaqueId, contextName, provider) {
        this.contextContainer.registerContext(pluginOpaqueId, contextName, provider);
      },
      registerRoute(pluginOpaqueId, path, handler) {
        this.handlers.set(
          path,
          this.contextContainer.createHandler(pluginOpaqueId, handler)
        );
      }
    }
  }
}

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

Pinging @elastic/kibana-platform

[elasticmachine]

💔 Build Failed

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

[joshdover]

retest

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💚 Build Succeeded

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

[joshdover]

Still working on some of the updates requested here but have to go for the day, should have this updated tomorrow.

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💔 Build Failed

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

[joshdover]

retest

[elasticmachine]

💚 Build Succeeded

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

[mshustov]

ack: will review by the end of the week

[elasticmachine]

💚 Build Succeeded

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

[mshustov]

is it a necessary declaration?

[joshdover]

Maybe not. I thought it could be useful to help show that the contextName parameter in registerContext corresponds to keys on this object.

[eliperelman]

Can you elaborate on why we are using arrow functions here instead of class methods?

[joshdover]

Without using function properties, I was having issues with this being the caller. I'll play around with this more to see if it's necessary.

[eliperelman]

Does this have any consequence in trying to pass in a Map?

[joshdover]

This function doesn't modify the argument and Map is compatible with ReadonlyMap so this change just makes this function more generally useful.

[elasticmachine]

💚 Build Succeeded

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

Comments addressed

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💚 Build Succeeded

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

[mshustov]

Good start. Let's try API with real use cases for the application and HTTP services.

[elasticmachine]

💔 Build Failed

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