-
Notifications
You must be signed in to change notification settings - Fork 747
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
Basic example pallet refactor #1707
Conversation
Yes, I very much like this. And in this example, really demonize
Fine with that, but please demonize them and highly encourage the reader to use alternatives such as:
|
@@ -82,6 +96,8 @@ pub use weights::*; | |||
|
|||
/// A type alias for the balance type from this pallet's point of view. | |||
type BalanceOf<T> = <T as pallet_balances::Config>::Balance; | |||
|
|||
/// A way to calculate transaction fees for our custom weight calculator. | |||
const MILLICENTS: u32 = 1_000_000_000; | |||
|
|||
// A custom weight calculator tailored for the dispatch call `set_dummy()`. This actually examines |
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.
A pretty useful step is to also remove WeightForSetDummy
and everything around it. We never implement this WeighData
manually (see for yourself if you can find any), yet we are providing an example of it.
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.
Instead, provide a reasonable and concise intro into what weights are, else keep them a constant for now.
Or make the pallet dev_mode
.
In any case, this WeightForSetDummy
is noise though in my opinion.
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.
Yeah I agree - this was some stuff left from a long time ago. It could make for some good learning material about how weights work eventually - in particular implementing ClassifyDispatch and PaysFee. Though here it is noise. I'll remove it. This will also drastically simplify the pallet!
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.
In the last commits I removed all custom weight stuff. Now I'm unsure whether to:
- Provide proper benchmarked weights for
set_dummy
- OR make the pallet
dev_mode
We already have a pallet that show cases dev_mode and I like how this example pallet provides the correct way for setting weights, plus using the macro for Inherited weight annotation for pallet calls
which we show can be overriden, so I currently just set the weight for set_dummy
to 0
to show this - though I'm weary about promoting this even as an example as it's not something any runtime dev should ever do.
Wdyt @kianenigma ?
} | ||
} | ||
|
||
// The call declaration. This states the entry points that we handle. The | ||
/// Events are a simple means of reporting specific conditions and |
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.
weird line wrapping.
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.
Does not seem resolved.
// Information about where this dispatch initiated from is provided as the first argument | ||
// "origin". As such functions must always look like: | ||
// The parenthesized value of the `#[pallet::weight(..)]` attribute can be any type that | ||
// implements the following traits: |
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.
Yeah I would remove these. maybe, maybe a deep deep dive on weights can covert this. Otherwise for now I would just mention it can be any expression that returns either number
, or (number, Pays)
with a couple of examples.
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.
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.
Unresolved.
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 removed this in the last commits as per my last comment about removing custom weight stuff.
// in system that do the matching for you and return a convenient result: `ensure_signed`, | ||
// `ensure_root` and `ensure_none`. | ||
// The weight for these calls relies on `WeightInfo`, which is auto-generated from the | ||
// benchmark toolchain. | ||
#[pallet::call(weight(<T as Config>::WeightInfo))] | ||
impl<T: Config> Pallet<T> { |
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.
reviewed up until this point. Will do another pass once existing comments are addressed.
/// | ||
/// In this call example, we use our own weight object `WeightForSetDummy` to determine the | ||
/// weight of this call. This overrides the `WeightInfo` type used to derive weights for | ||
/// other calls in this block. | ||
#[pallet::call_index(1)] | ||
#[pallet::weight(WeightForSetDummy::<T>(<BalanceOf<T>>::from(100u32)))] | ||
pub fn set_dummy( | ||
origin: OriginFor<T>, | ||
#[pallet::compact] new_value: T::Balance, |
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 feel like the use of the #[pallet::compact]
attribute macro here should be commented on, e.g. why would you want to use it when setting a balance, but not when increasing it (see function signature of accumulate_dummy
)
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.
Thanks for the preliminary review @kianenigma and @wentelteefje. Part of me looking for first impressions was to see whether it's reasonable to completely remove some of the things this pallet highlights (like SignedExtensions, Weights, and other distractions that ultimately should be either in their own ref docs or have their own pallet). And it seems we're aligned that this should be the direction I take. I've applied your suggestions and will continue improving and using docify in the actual pallet code to demonstrate behavior there.
Since I'm essentially re-writing the basic example pallet, I've created a new pallet to isolate the examples around the basic use of StorageValue only. If we like this direction (of creating separate example pallets to demonstrate specific FRAME features), I'll go ahead and create others to demonstrate a signed extension and hooks in separate example pallets. These can become a useful place to easily grasp some of FRAME's core features in action. Can you have another look @kianenigma and tell me what you think about this direction? |
/// | ||
/// `frame_system::Config` should always be included. | ||
/// Because all FRAME pallets depend on some core utility types from the System pallet, | ||
/// [`frame_system::Config`] should always be included. This pallet example uses the `Balances` |
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.
Things like Config
have some default doc that is generated by the pallet macro for them as well, FYI. If you provide your own docs, it will be overwritten.
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 have some general concerns about dummy-storage-value
as a single example pallet (communicated elsewhere).
In any case, I suggest we keep this PR limited to just refactoring the basic example pallet.
This reverts commit 5037b55.
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
The CI pipeline was cancelled due to failure one of the required jobs. |
The CI pipeline was cancelled due to failure one of the required jobs. |
The goal here is to simplify the basic example pallet to make it more readable and better highlight the features it demonstrates. Looking for initial feedback and comments (cc @kianenigma).
Here's a list of things I've done to that end:
on_initialize
in the tests: we don't actually do anything withon_initialize
, we could probably have another example pallet focuses on demonstrating it. I still left theon_initialize
andon_finalize
hooks in the pallet because the comments already there gives the reader the basic idea of how to declare those hooks and what they doMagicNumber
constant: we have the default config example pallet to refer to already and we weren't demonstrating it's use here anywaysaccumulate_dummy
and simplified itOther changes:
Foo
toDummyValueQuery
to highlight the use ofValueQuery
WatchDummy
toWatchSetDummy
to avoid confusion on what the SignedExtension is doingTodo: