'before op': (ops: [any], source: any, clientId: string) => void;

    'op': (ops: [any], source: any, clientId: string) => void;

We should match the (upcoming) update to Connection

This is a speculative fix for https://github.com/share/sharedb/issues/502

It seems impossible to get this test to fail locally, so this change makes some generic quality-of-life improvements on the test code in the hopes that we improve its stability:

• wait for the insert and removes to be acked on connection2 before reconnection connection
• catch del() errors
• change the query listeners to .once() to avoid multiple calls

Fixes https://github.com/share/sharedb/issues/503

This change fixes a flaky test, which relies on a setTimeout with a 10ms wait.

This change replaces the use of a setTimeout with an event listener, which is not prone to flakiness, and is more semantic.

(I personally find | null to be noise in TS, because every property can be set to null, so it doesn't really add anything, but fine)

The type definition for the Connection class is currently missing most of its instance properties. This change adds the non-prefixed properties to the type definitions.

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Test the change in your own code. (Compile and run.)
• [x] Add or edit tests to reflect the change.
• [x] Follow the advice from the readme.
• [x] Avoid common mistakes.
• [x] Run npm test <package to test>.

If changing an existing definition:

• [x] Provide a URL to documentation or source code which provides context for the suggested changes: <<url here>>
• [x] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.

(On this, in future I think we should potentially provide the corresponding ShareDB lifecycle hook, but definitely out-of-scope for this change)

I'm not really sure this should live on options — isn't that the object ShareDB called the driver with?

I think it probably makes more sense for triggeredBy to just be an (optional) top-level property in request.

Why is this an anti pattern?

I think it's an anti-pattern, because a purist would argue that this use of generics offers no "real" type safety. For example, a classic example of a generic might be the Array:

const arr = new Array<number>();
arr.push(1);
const item: number = arr.pop();

The generic here offers type-safety, because it ties everything about the class together: you definitely can only add a number, and always are guaranteed to get a number.

If the Array (hypothetically) let you override its generic types on its instance methods, you could write something like:

const arr = new Array(); // Defaults to any
arr.push<number>(1);
const item = arr.pop<string>();

...then you've not gained anything from the type system, and you're just abusing the fact that the methods let you override the expected type — essentially you've just cast the result — which then begs the question of what value is the type system adding here.

If we follow our wrapper.find<HTMLElement>() {} to its logical extreme, it's akin to writing:

function foo<T extends any = any>(): T {}
const bar = foo<string>();

...which really offers no more type safety than this:

function foo(): any {}
const bar = foo() as string;

Using as XXX allows you to write any type, which might not be valid

That is not the case:

However, all that being said, as a pragmatist, I do think if we're going to be forced to constantly cast our find() results, then this syntax:

wrapper.find<HTMLElement>('.foo').element.click()

is arguably "nicer" than this syntax:

(wrapper.find('.foo').element as HTMLElement).click()
// Or alternatively...
(<HTMLElement> wrapper.find('.foo').element).click()

Then shouldn't we be passing these options everywhere we call find()?

Ready to merge

I think it's weird to force true in the type definition. It's perfectly valid to write code that programmatically requests metadata:

const options = {
  opsOptions: {
    metadata: shouldFetchMetadata(),
  },
};

function shouldFetchMetadata(): boolean {
  // Do complex logic to determine if we want to fetch metadata
}

As a side-note, it sounds like using this sort of generic typing where the type isn't used in the parameter list is an anti-pattern, and I guess now I think about it, I don't really understand the value of doing this over just forcing consumers to cast:

const button = wrapper.find('.button') as HTMLButtonElement;

Yes it's fine if you reference by element tag, but I personally tend to avoid that to keep tests from being too fragile (and often looking things up by just eg div are usually not specific enough).

The scope of this PR was just to make the change un-breaking; so if you want to adopt the v3 types, that should probably be a different change.