HOTFIX: fix subscription narrowing problem

[vejrj]

No description provided.

[alloy]

I’m missing an example of what the resolver implementation would look like. Is this requiring folks to include the kind property in their implementation?

[vejrj]

I’m missing an example of what the resolver implementation would look like. Is this requiring folks to include the kind property in their implementation?

Yes, you will need to add kind for "SubscribeAndResolve"

[alloy]

That doesn’t seem helpful. At that point it’s more intuitive to export two different type definitions.

[vejrj]

That doesn’t seem helpful. At that point it’s more intuitive to export two different type definitions.

That was my initial idea, but @freiksenet said that we would need to refactor everything then.

[alloy]

Can you elaborate on the difference in effort needed to add kind vs using a different type? Both can be done relatively the same way with a codemod afaik.

[alloy]

As discussed offline, I consider this solution a no-go. We provide framework solutions and we need to consider our customers [the product engineers], and this workaround is not intuitive. We should:

1. Figure out if it's simply not possible to provide a single type and have TypeScript correctly narrow the union;
2. and otherwise provide 2 types and have the product engineer choose the right one—which is something that they can intuitively understand.