Add fetch function helpers to accounts page

[wjthieme]

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]

🦋 Changeset detected

Latest commit: 560ebef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@codama/renderers-rust	Patch
@codama/renderers	Patch

Not sure what this means? Click here to learn what changesets are.

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

[lorisleiva]

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

[wjthieme]

@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]

@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]

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]

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]

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]

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]

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]

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?

[wjthieme]

@lorisleiva moved the types to the sharedPage

[lorisleiva]

Thanks @wjthieme! Could you run the tests locally so it generates the changes in the end-to-end tests and push the changes in a commit? Otherwise CI will fail. This will also help me see the generated changes when I review to double check everything is okay. We'll also need a changeset for the Rust renderer. a patch should be okay.

[wjthieme]

@lorisleiva added the changeset and found that the sharedPage was never rendered anywhere in the rust client. I proposed a fix but wasn't fully sure when it should be rendered or not. Let me know if my implementation is correct!

[lorisleiva]

Just waiting for CI to pass but looks good otherwise, thanks!

@febo are you happy with this?

[lorisleiva]

Thanks! Could you just re-run the tests locally and commit the changes so the e2e folders are updated as well?

[febo]

The sharedPage looks good now. As Loris mentioned, we just need to update the examples.

[lorisleiva]

Thank you! 🍺