While the current solution is quite clean, its usage might turn out to be onerous (the vanilla way is to have a target pallet as a dependency). However, one can always prepare the object call manually without pallet (e.g. with subxt), encode it and then decode it :shrug:
This problem will rise in ink! integration, where we have to implement:
where Value comes from subxt. For this however, I will try to change the API there a bit (it was designed for subxt only). Then, integration with this new code should be much easier.
closes #36
While the current solution is quite clean, its usage might turn out to be onerous (the vanilla way is to have a target pallet as a dependency). However, one can always prepare the object call manually without pallet (e.g. with subxt), encode it and then decode it :shrug:
This problem will rise in ink! integration, where we have to implement:
where
Value
comes fromsubxt
. For this however, I will try to change the API there a bit (it was designed for subxt only). Then, integration with this new code should be much easier.