-
Notifications
You must be signed in to change notification settings - Fork 125
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 api traits #363
Add api traits #363
Conversation
add missing file make clippy happier cargo fmt redo compose_extrinsic macro. Did not work before fix doc Bump secp256k1 from 0.24.0 to 0.24.2 (#364) Bumps [secp256k1](https://github.com/rust-bitcoin/rust-secp256k1) from 0.24.0 to 0.24.2. - [Release notes](https://github.com/rust-bitcoin/rust-secp256k1/releases) - [Changelog](https://github.com/rust-bitcoin/rust-secp256k1/blob/secp256k1-0.24.2/CHANGELOG.md) - [Commits](rust-bitcoin/rust-secp256k1@secp256k1-0.24.0...secp256k1-0.24.2) --- updated-dependencies: - dependency-name: secp256k1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> add submitextrinsic trait Added Polkadex in substrate-api-client readme (#365)
e8c3419
to
7f9b278
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally, the monolith has been separated!
However, I think that the separation is not really coherent with the substrate structure. What I propose to cleanly separate the stuff:
rpc_implementatsions/
chain
state
constants
frame_system
pallet-balances
pallet-transaction-payment
I do wonder if we should split up the subscriptions and put them into the respective domain, e.g.,
subscribe_finalized_head
-> chain
is this queries the chain
RPC of the substrate node.
On the other hand, this would introduce a bit more complexity. I am unsure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved all subscription, where possible, to the correspondent file. I think it makes more sense than to have all subscriptions in one file.
src/api/interfaces/subscription.rs
Outdated
use sp_core::storage::StorageChangeSet; | ||
|
||
// FIXME: This should rather be implemented directly on the | ||
// Subscription return value, rather than the api. Or directly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like how it's currently done. But changing this would break the interface. So that should be done in a different PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now, we only have events here. Maybe we can call it EventSubscription
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, actually, following the rust convention, that should rather be a verb noun. How about SubscribeEvents
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree that is even better, but the last thing would to also rename the file accordingly to subscribe_events
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, looks much cleaner! A few minor remarks remain though. :)
src/api/interfaces/subscription.rs
Outdated
use sp_core::storage::StorageChangeSet; | ||
|
||
// FIXME: This should rather be implemented directly on the | ||
// Subscription return value, rather than the api. Or directly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now, we only have events here. Maybe we can call it EventSubscription
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much better now, I really like it. One last thing remains. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoopwhoop!
Adds traits to the api and removes obsolete impl enforcements on the Api where possible (see #357)
closes #267