This PR refactors the way we handle custom environment-based building blocks. Previously, we used two separate traits — ToEncode and EnvironmentEncode — to manage encoding logic. This approach has now been streamlined.
What's Changed
Instead of relying on custom encoding traits, we now focus on converting environment variables directly into ManifestValue. These values are then passed normally to the manifest_args!() macro, eliminating the need for additional encoding logic and simplifying the interface.
To support this, the new ToValue trait has been introduced:
pub trait ToValue {
fn to_value<'a>(
&self,
test_engine: &mut TestEngine,
manifest_builder: ManifestBuilder,
caller: ComponentAddress,
) -> (ManifestBuilder, ManifestValue);
}
Benefits
- Simplifies the process of supporting custom types in test manifests.
- Reduces boilerplate and avoids redundant trait implementations.
- Enables cleaner, more expressive code when dealing with environment variables.
Example: Handling Optional Environment Variables
We’ve introduced an EnvOption enum to model optional environment values, along with its ToValue implementation:
pub enum EnvOption {
None,
Some(Box<dyn ToValue>),
}
impl ToValue for EnvOption {
fn to_value(
&self,
test_engine: &mut TestEngine,
manifest_builder: ManifestBuilder,
caller: ComponentAddress,
) -> (ManifestBuilder, ManifestValue) {
match self {
EnvOption::Some(element) => {
let (manifest_builder, inner_value) = element.to_value(test_engine, manifest_builder, caller);
(
manifest_builder,
Value::Enum {
discriminator: 1,
fields: vec![inner_value],
},
)
}
EnvOption::None => (
manifest_builder,
Value::Enum {
discriminator: 0,
fields: vec![],
},
),
}
}
}
Additional Improvements
We also added dedicated environment types for the four supported address kinds:
EnvResource
EnvAccount
EnvComponent
EnvPackage
This makes it easier to implement custom types and simplifies manifest parameter construction.
Example: Custom Tuple Type
Here’s how we define a custom type representing a (ComponentAddress, FungibleBucket) tuple:
struct CustomType<N: ReferenceName + Clone, T: ResourceReference + Clone>(
EnvComponent<N>,
Fungible<T>,
);
impl<N: ReferenceName + Clone, T: ResourceReference + Clone> ToValue for CustomType<N, T> {
fn to_value(
&self,
test_engine: &mut TestEngine,
manifest_builder: ManifestBuilder,
caller: ComponentAddress,
) -> (ManifestBuilder, ManifestValue) {
let (manifest_builder, address) = self.0.to_value(test_engine, manifest_builder, caller);
let (manifest_builder, bucket) = self.1.to_value(test_engine, manifest_builder, caller);
let value = Value::Tuple {
fields: vec![address, bucket],
};
(manifest_builder, value)
}
}
Let me know if you'd like a shorter version for internal use or one tailored for external contributors!
This PR refactors the way we handle custom environment-based building blocks. Previously, we used two separate traits —
ToEncodeandEnvironmentEncode— to manage encoding logic. This approach has now been streamlined.What's Changed
Instead of relying on custom encoding traits, we now focus on converting environment variables directly into
ManifestValue. These values are then passed normally to themanifest_args!()macro, eliminating the need for additional encoding logic and simplifying the interface.To support this, the new
ToValuetrait has been introduced:Benefits
Example: Handling Optional Environment Variables
We’ve introduced an
EnvOptionenum to model optional environment values, along with itsToValueimplementation:Additional Improvements
We also added dedicated environment types for the four supported address kinds:
EnvResourceEnvAccountEnvComponentEnvPackageThis makes it easier to implement custom types and simplifies manifest parameter construction.
Example: Custom Tuple Type
Here’s how we define a custom type representing a
(ComponentAddress, FungibleBucket)tuple:Let me know if you'd like a shorter version for internal use or one tailored for external contributors!