Closed Kayanski closed 1 month ago
Latest commit: |
8547823
|
Status: | ✅ Deploy successful! |
Preview URL: | https://7d8e9db5.cw-orchestrator.pages.dev |
Branch Preview URL: | https://nicolas-orc-145-re-export-ib.cw-orchestrator.pages.dev |
How often are those types used?
How often are those types used?
Create channel requires PortId. I'm not a huge fan of "portid".parse().unwrap()
as it's not very clear to which type it's getting parsed and it's the only way to not re-export same version of ibc-relayer-types
I don't understand. This crate will also be included in wasm build (it's not wasm featured).
And even then I'm unsure about whether this is needed. Can we accept in Into<String>
for that fn and parse internally instead?
And even then I'm unsure about whether this is needed. Can we accept in
Into<String>
for that fn and parse internally instead?
PortId have few helpful infallible creation method like commonly used PortId::transfer()
. I'm ok to take AsRef<str>
and parse it internally as well!
I don't understand. This crate will also be included in wasm build (it's not wasm featured).
And even then I'm unsure about whether this is needed. Can we accept in
Into<String>
for that fn and parse internally instead?
This is possible yes. We have discussed about variables naming and I think that those types come in handy. We could also get rid of them, but that would make the API less clear as well.
In another topic, I made the dependency wasm protected
This PR aims at re-exporting the ibc-relayer-types needed inside cw-orch-interchain::env. This allows users to not import
ibc-relayer-types
crate when integrating and using cw-orch-interchainChecklist