Mock ES6 Classes in New Platform

[mshustov]

Description

We need to figure out the way to mock dependencies defined as ES6 Class. Our current approach implies we mock only external methods of the class, thus when we pass a mock to a function that expects real ES6 Class we get incompatibility error.

Example
https://github.com/elastic/kibana/pull/32999/files#diff-71ede491c56cdaa1766ec8a3a434cd36R38
If you remove a manual type casting you can see an error due to lack of class internals.
...missing the following properties from type 'UiSettingsClient': update$, saved$, api...

Related discussion

#32300 (comment)
#31486
microsoft/TypeScript#18499

Proposed solutions

mute error and wait for real private fields supported in TS 😄

toasts: (toastsServiceMock.createStartContract() as unknown) as ToastsStart,

Disadvantages No type check, it's not critical because actually we have a guarantee for public methods, as this type check is already made in https://github.com/elastic/kibana/pull/32999/files#diff-ef336fc230d3646d86f73486ed09ec05R22

Separate interface declaration and implementation

#32300 (comment)

// config.js
class ConfigService implements IConfigService {...
// server.js
class Server {
  constructor(configService: IConfigService, ...)

disadvantages introduces additional concept - a public interface, also forces to define all method types manually!

export interface IToastsStart {
  get$: () => Rx.Observable<Toast[]>;
  add: (toastOrTitle: ToastInput) => Toast;
  remove: (toast: Toast) => void;
  addSuccess: (toastOrTitle: ToastInput) => Toast;
  addWarning: (toastOrTitle: ToastInput) => Toast;
  addDanger: (toastOrTitle: ToastInput) => Toast;
}
// or more confusing syntax, but less verbose
export type IToastsStart = PublicMethodsOf<ToastsStart>;

the full example master...restrry:example-with-interface

make mocks to extend class implementation #32300 (comment)

disadvantages in the comment ^^

[elasticmachine]

Pinging @elastic/kibana-platform

[mshustov]

@elastic/kibana-platform thoughts?

[joshdover]

I prefer defining explicit interfaces that can be implemented as classes or objects.

Though it's more verbose, it has one key advantage: the ability to separate the public interface from the internal one that may have more APIs. For instance, the ChromeService has APIs that are available to plugins and ones that are only meant to be consumed by other Core services. With the interface approach we can declare the public APIs explicitly and still avoid having to duplicate the internal ones:

/** @public */
export interface ChromeStart {
  setBrand(brand?: string): void;
}

/**
 * This can be grabbed via `ReturnType` since we don't need to generate pretty docs
 * @internal
 */
export type InternalChromeStart = UnrwapPromise<ReturnType<ChromeService['start']>>;

class ChromeService implements CoreService<void, ChromeStart> {
  public async start() {
    return {
      setBrand() {},
      /** Internal-only API */
      getComponent(): JSX.Element {
        return <div>Hi</div>;
      },
    };
  }
}

In light of #34416 needed to support good API docs, we need explicit interfaces anyways and this approach does not create any additional work.

[joshdover]

@elastic/kibana-platform Just a reminder that we decided to come to a consensus on the solution here sooner than later. Any thoughts on what I proposed?