You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 14, 2023. It is now read-only.
In the dynamic case, devs may run into issues when supplying the dynamic data to methods of the fluent API.
chain.pallet(palletName)// ~~~~~~~~~~// ^// `string` is not assignable to Chain.PalletName<Chain>
Possible Solutions
1. chain.untyped()
We could introduce a dynamic method to ChainRune. This would allow devs to opt out of the narrow, chain-specific constraints.
myChain.untyped().pallet(palletName)// no more type error
2. Generate Guards + Assertions
Alternatively, we could generate guards that do this narrowing.
import{chain,assertPallet,isStorage}from"@capi/chain"palletName// `string`assertPallet(palletName)palletName// `Chain.PalletName<Chain>`constpallet=chain.pallet(palletName)// no more type errordeclareconststorageName: stringif(isStorage(pallet,storageName)){conststorageName=pallet.storage(storageName)// ...}
Tradeoffs
The first solution probably lends itself to faster prototyping. The second solution probably results in nicer error messages and safer code (albeit more code). We could also have both, and prefix untyped with unsafe to discourage devs from shipping prod code that uses it. unsafeUntyped sounds scary indeed!
Thank you @arrudagates for pointing out this use case!
The text was updated successfully, but these errors were encountered:
harrysolovay
changed the title
opting out of narrow chain type
passing dynamic data to codegened API methods
Jul 14, 2023
Problem Statement
Developers will want to colocate static and dynamic usage of a given chain. Examples of both:
Static
Dynamic
In the dynamic case, devs may run into issues when supplying the dynamic data to methods of the fluent API.
Possible Solutions
1.
chain.untyped()
We could introduce a
dynamic
method toChainRune
. This would allow devs to opt out of the narrow, chain-specific constraints.2. Generate Guards + Assertions
Alternatively, we could generate guards that do this narrowing.
Tradeoffs
The first solution probably lends itself to faster prototyping. The second solution probably results in nicer error messages and safer code (albeit more code). We could also have both, and prefix
untyped
withunsafe
to discourage devs from shipping prod code that uses it.unsafeUntyped
sounds scary indeed!Thank you @arrudagates for pointing out this use case!
The text was updated successfully, but these errors were encountered: