Add ContextService

[joshdover]

Summary

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

For now this is exposed as an internal-only service that Core services can use to add context registration and context construction to their service. For example, this will be used in the ApplicationService like so:

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

  public setup() {
    return {
      registerApp: (app: App) =>
        this.apps$.next([...this.apps$.value, app]),
      registerContext: (contextName, provider) => 
        this.mountContext.register(contextName, provider, plugin),
    };
  }

  public async start({ context }) {
    const mountContext = context.createContextContainer<ApplicationContext>();
    
    // use mountContext.createContext(); when mounting an application

    return {
      registerContext: mountContext.register
    };
  }
}

To do in future PRs:

• Create a pattern for exposing plugin-scoped service contracts for core services
• Create a pattern for exposing plugin-scoped plugin contracts for plugins
• Expose this service to plugins
• Add a parallel service to the server-side

Checklist

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

• Documentation was added for features that require explanation or tutorials
• 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 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

[elasticmachine]

Pinging @elastic/kibana-platform

[elasticmachine]

💚 Build Succeeded

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

[elasticmachine]

💚 Build Succeeded

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

[eliperelman]

Looks really good! Left a couple small nits.

[eliperelman]

I know I keep beating a dead horse on this one, but do we know why TypeScript doesn't infer this correctly?

const createMock = (): jest.Mocked<ContextServiceContract> => ({
  setup: jest.fn().mockReturnValue(createSetupContractMock()),
});

It seems strange that we need to create temporary throw-away variables to satisfy some problem with typing here.

[joshdover]

I think @restrry knows more. I believe it's a fixable problem in DefinitelyTyped but not sure if it's been fixed yet?

[mshustov]

jest doesn't know which function it mocks. if we want to have type safety, we should provide types manually
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jest/index.d.ts#L120-L127
There are several options

• define a type manually for every function

type Arguments<T> = T extends (...args: infer U) => any ? U : never;
//...
const mock = {
    start: jest
      .fn<
        ReturnType<typeof createStartContractMock>,
        Arguments<typeof createStartContractMock>
      >()
      .mockReturnValue(createStartContractMock),
}

• or define a result type

const mock: jest.Mocked<ContextServiceContract> = {
    start: jest.fn(),
}
// and now, knowing the result type, jest can check whether a passed value satisfies the type
mock.start.mockImplementation(createStartContractMock);

when you declare a type as:

const createMock = (): jest.Mocked<ContextServiceContract> => ({
  setup: jest.fn().mockReturnValue(createSetupContractMock()),
});

TS uses this declaration https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jest/index.d.ts#L123
and infers a type as jest.fn<any, any>

Thus, any value passed as mockReturnValue or mockImplementation satisfies this type.

probably there is a better solution I'm not aware of.

[elasticmachine]

💚 Build Succeeded

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

Fixed!

[mshustov]

never met service owner terminology in our code so far. is it core service?
If no, what if a plugin calls register without pluginName?

.register('ctxFromPluginA', context => ..);

now the result is provided to the all plugins, even if they have no dependency on pluginA.

[joshdover]

This will have to be made impossible by the service owner (which can be a Core service or a plugin).

The service owner that exposes this context container's register method should populate the pluginName argument based on the scoped service contract pattern in #40822

[mshustov]

should we add a test to check an exception, raised during register phase, bubbles to the caller?

[joshdover]

I'm not sure what you mean? Do you mean that we move / duplicate this test to ContextService?

[mshustov]

jest doesn't know which function it mocks. if we want to have type safety, we should provide types manually
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jest/index.d.ts#L120-L127
There are several options

• define a type manually for every function

type Arguments<T> = T extends (...args: infer U) => any ? U : never;
//...
const mock = {
    start: jest
      .fn<
        ReturnType<typeof createStartContractMock>,
        Arguments<typeof createStartContractMock>
      >()
      .mockReturnValue(createStartContractMock),
}

• or define a result type

const mock: jest.Mocked<ContextServiceContract> = {
    start: jest.fn(),
}
// and now, knowing the result type, jest can check whether a passed value satisfies the type
mock.start.mockImplementation(createStartContractMock);

when you declare a type as:

const createMock = (): jest.Mocked<ContextServiceContract> => ({
  setup: jest.fn().mockReturnValue(createSetupContractMock()),
});

TS uses this declaration https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jest/index.d.ts#L123
and infers a type as jest.fn<any, any>

Thus, any value passed as mockReturnValue or mockImplementation satisfies this type.

probably there is a better solution I'm not aware of.

[elasticmachine]

💔 Build Failed

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

Comments addressed

[joshdover]

retest

[joshdover]

Closing this PR while I experiment with an alternative idea.

[elasticmachine]

💔 Build Failed

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