search

codama-idl / codama

Generate clients, CLIs, documentation and more from your Solana programs
MIT License
103 stars 19 forks source link

Add fetch function helpers to accounts page #299

Open wjthieme opened 3 weeks ago

wjthieme commented 3 weeks ago

Fetch helper functions are currently included in the js client but not in the rust client. This PR adds similar fetch helper functions to the rust renderer.

I've added it behind a feature flag because it requires solana-client and solana-sdk crates which you don't want for CPIs.

Let me know what you think!

changeset-bot[bot] commented 3 weeks ago

⚠️ No Changeset found

Latest commit: e3185b850a81f2d879d17455f056e1be1ce771c5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

lorisleiva commented 3 weeks ago

Oh interesting, thanks for that! @febo any thoughts about shipping this?

wjthieme commented 1 week ago

@febo if you could look at this that would be great! One thing I am not 100% sure about is that with this change every generated client will have their own version of DecodedAccount and MaybeAccount which won't be interoperable.

febo commented 1 week ago

@febo if you could look at this that would be great! One thing I am not 100% sure about is that with this change every generated client will have their own version of DecodedAccount and MaybeAccount which won't be interoperable.

This is very nice! You are right that by having the DecodedAccount and MaybeAccount accounts on each generated client will make them "different" types. That will probably be annoying if you are using two different client together.

Perhaps what we could do is to define these types and maybe the logic for the fetch_* methods on a separate crate and use this crate on the generated clients. We could call the crate codama-rpc – @lorisleiva what do you think in having a repository for this?

wjthieme commented 1 week ago

Also, I think it might be more useful to use nonblocking rpc client instead for the fetch functions (the caller can make an async function sync by blocking or using a runtime but not the other way around). If that sounds good I can make that change!

(we could also do both blocking and nonblocking in different sub-modules)

lorisleiva commented 1 week ago

Perhaps what we could do is to define these types and maybe the logic for the fetch_* methods on a separate crate and use this crate on the generated clients. We could call the crate codama-rpc – @lorisleiva what do you think in having a repository for this?

I 100% think we need to have an external crate that is being used by the generated code to avoid code repetition. But I don't think this is Codama. This the equivalent of the new Web3.js for the JavaScript renderer. We need something like "Web3.rs" for the Rust renderer. In other words, a Rust client framework that includes something akin to codecs and helpers functions like the ones introduced in this PR.

febo commented 1 week ago

Perhaps what we could do is to define these types and maybe the logic for the fetch_* methods on a separate crate and use this crate on the generated clients. We could call the crate codama-rpc – @lorisleiva what do you think in having a repository for this?

I 100% think we need to have an external crate that is being used by the generated code to avoid code repetition. But I don't think this is Codama. This the equivalent of the new Web3.js for the JavaScript renderer. We need something like "Web3.rs" for the Rust renderer. In other words, a Rust client framework that includes something akin to codecs and helpers functions like the ones introduced in this PR.

Nice, this is a good idea. @wjthieme Would you like to create this repo with the helpers and we can then use it on the renderers? The helpers will probably be independent of the Codama client, like, you could use them standalone in any application.

Once this is available as a crate, we can update this PR to make use of that and avoid duplicating the types/logic.

wjthieme commented 1 week ago

The helpers will probably be independent of the Codama client

I'd be down to create this. Do you have a location in mind for the repo or doesn't really matter?

febo commented 6 days ago

The helpers will probably be independent of the Codama client

I'd be down to create this. Do you have a location in mind for the repo or doesn't really matter?

I don't think it matters – happy to help with naming, etc.

lorisleiva commented 5 days ago

FYI, @joncinque and I recently talked about moving away from kaigan crate in order to use a more encompassing crate as a "client framework" that can then be used by the generated code. It looks like there's some work overlap here so maybe we could set up a call to define/plan this?