Configurable Config and Extra types
#373
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Dec 16, 2021
jsdw
reviewed
Jan 5, 2022
| Self(account_id) | ||
| } | ||
| } | ||
|
|
||
| pub struct RuntimeApi<T: ::subxt::Config + ::subxt::ExtrinsicExtraData<T>> { | ||
| pub struct RuntimeApi<T: ::subxt::Config, E> { |
There was a problem hiding this comment.
Is it worth defaulting these generic params eg
pub struct RuntimeApi<T: ::subxt::Config = ::subxt::DefaultConfig, E = ::subxt::DefaultExtra<::subxt::DefaultConfig>> {
so that we don't have to specify them when instantiating the RuntimeApi unless they differ? Or is the common case that you'll need to specify different ones, so it may as well be explicit?
There was a problem hiding this comment.
I'm not sure TBH, on the one hand it is very convenient if you are using the defaults, on the other if they are hidden then there is not the clue that it is configurable.
I'd lean towards leaving it explicit for now, until the api has solidified and we have an idea of the common usage.
jsdw
approved these changes
Jan 5, 2022
0623forbidden
pushed a commit
to DEIPworld/substrate-subxt
that referenced
this pull request
Feb 15, 2022
* WIP config * WIP separate default config * Separate trait impls on client * WIP introduce new ApiConfig (to be renamed) trait * Update generated polkadot codegen * Allow configuring Config and Extra types independently * Add extra default configuration * Revert ir parsing of config attr * Add default-features = false to substrate deps * Revert "Add default-features = false to substrate deps" This reverts commit 099d20c.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #331
Currently the
ConfigandExtratrait implementations are hardcoded by the macro, which means that if the target runtime has different types or extrinsic signed extensions, then it will not work.This PR enables the user to supply their own implementations of
ConfigandExtraas parameters to theRuntimeApitype generated by the macro. E.g.Here we are using the built in default implementations as type parameters, but the user is now able to supply their own implementations in their place.
This may not be the final API, since we also need to consider how we can integrate the initialisation of some of the additional signed data (e.g. transaction payment), which currently have default values set. Also we will probably want to use metadata to have the macro generate the correct set of signed extensions, rather than requiring them to be hardcoded upfront.
However these things can be built upon this foundation, which at least allows the user the ability to customise these previously hardcoded types.