Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add TS demo that attempts to get invoke types correct #7

Closed
wants to merge 2 commits into from

Conversation

chadoh
Copy link

@chadoh chadoh commented Jul 10, 2023

What

For stellar#753, I want to make sure that invoke and all the auto-generated functions in index.ts actually return correct types. This adds a self-contained figuring-out-types.ts file that demonstrates that this hasn't been figured out yet.

Why

People will use these functions all the time, and probably mostly in their most simple form.

  • If I call balance({ address: 'GAAA…' }), I want my editor to know that it's a bigint.
  • If I call balance({ address: 'GAAA…', responseType: 'simulated' }), I want my editor to know that it's a SorobanClient.SorobanRpc.SimulationResponseType.

So far, I've been able to get the types to return correctly if you explicitly set responseType, but not for the simplest, most common call type.

Known limitations

[TODO or N/A]

if you check the inferred return types for the examples in
`figuring-out-types.ts`, you'll see that the ones that leave `options`
totally undefined/empty for `invoke` return an intersection type
(`string | "sim" | "rpc"`), rather than the correct `T` (ie `string`).
something about the presence of T but _not_ R seems to really trip up
the type inference
@chadoh chadoh closed this Jul 11, 2023
@chadoh chadoh deleted the docs/figuring-out-types branch July 11, 2023 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant