I’m trying to create a code component that is using the external API with context-dependent methods and named args.
Speaking specifically, it is calling Ethereum blockchain, but this fact can be omitted within this question and considered as just some generic RPC API like call(entityID: string, methodName: string, ...args: string[])
, where possible methodName
options is list based on entityID
(like getMethods(entityID)
), and args
are named tuple based on entityID
and methodName
(like getArgs(entityID, methodName)
).
E.g. for specific kind of entity, args for method balanceOf
are expected as named tuple [address: string]
, and for allowance
it will be [owner: string, spender: string]
.
I’m currently using arg1, arg2...arg6
as tuple entities, but I want to make better developer experience for users of this component.
I’m currently using a hack to render the dynamic description, but it can be unstable in future. This is how things looks like when using this hack:
I wish to have some dynamic values instead of Arg1, Arg2 and so on, and I do not want to rely on hack in render of helpText
and other attributes.
I’m kindly requesting for API support of at least one following options:
- make
PropType.helpText
dynamic - similar to howhidden
works - as typestring | ContextDependentConfig<P, string>
.
(I assume it will only require to change this line to support helpText functions and change some types) - Same request additionally goes for
PropType.required
,PropType.exprHint
. I personally feel less urge in this properties but I assume this will be quite useful for others. - expose
name
/displayName
property asstring | ContextDependentConfig<P, string>
to make rendered key names controlled by component developer. - alternatively, it will be great if some attribute like
dynamicProps
will be implemented, that will acceptContextDependentConfig<P>
as input (with props only, without current dynamic props to avoid looping) and return object similar to props, that will be rendered below main props in editor sidebar.
I understand that I can create custom prop to solve this issue, but this will be looking not so good, and I also will lose the ability to use dynamic props, which is quite important for my case.
Additionally, it will be great if refActions
will be also dynamic in same manner (taking props into account), and if CodeComponentMeta.displayName
will be definable in dynamic manner for better user experience, but I understand this may be way more complicated to implement.