Fees API Improvement

[lemunozm]

Description

Problem

The current API provided by the traits around pallet_fees to handle fees has two negative points:

1. In order to use it in a pallet you need to use at least 2 associated types in the Config trait. i.e:

/// Entity used to pay fees
type Fees: Fees<AccountId = Self::AccountId>;

/// Key used to get the fee value.
type ActionAFeeKey: Get<<Self::Fees as Fees>::FeeKey>;

2. The knowledge of how to consume that fee is in the pallet when the pallet should not be aware of it. This should be a runtime concern.

/// Inside the pallet we decide when we should not do that
T::Fees::fee_to_treasury(&who, Fee::Key(T::ActionAFeeKey))?;
// or
T::Fees::fee_to_author(&who, Fee::Balance(T::ActionAFeeValue))?;

Solution

We can fix these 2 points by coding the whole fee action in different types (see PR code) under a new trait PayFee.

Pallet:

// In Config trait:
type ActionAPayFee: PayFee<T::Account>;

// When use it:
T::ActionAPayFee::pay_for(&who)?;

Runtime:

parameter_types! {
    pub const ActionAFee: Fee = Fee::Balance(10 * CFG);
}

impl pallet_example::Config for Runtime {
    // We set in one line:
    //   - How the fee is handled
    //   - The value of the fee
    type ActionAPayFee = FeeToTreasury<Fees, ActionAFee>;
    // ...
}

[lemunozm]

This PR is completed and ready for review

[NunoAlexandre]

Sweet 🍯 👌

[NunoAlexandre]

One doc request but not blocking 🙏

[NunoAlexandre]

Given the previous discussion, I would for sure document that who is the account that's paying for the fees and not the account that is receiving them.

[wischli]

+1 on that. Would also be great to rename who to payer.

[lemunozm]

Good point! Sorry for the "auto-merge", keep in mind for a future PR where I could add this 🧠

[lemunozm]

Here it goes: 2901f0e