[GTM-345]Define component props in class for doc discoverability #4183
Conversation
ElijahAhianyo
changed the title
| @@ -411,6 +411,12 @@ class CodeBlock(Component): | |||
| # Props passed down to the code tag. | |||
| code_tag_props: Var[Dict[str, str]] | |||
|
|
|||
| # Whether a copy button should appear. | |||
| can_copy: Var[Optional[bool]] = Var.create(False) | |||
There was a problem hiding this comment.
The other problem here is now these are annotated and treated as Var... but in many cases, the code in the create is using python if statements and potential other operations that are not valid on Var types.
I'd be more okay defining these as regular model fields (i.e. without the Var), but then i don't think they'd be automatically picked up by the pyi generator and the doc generation
There was a problem hiding this comment.
The regular model fields get picked up by the pyi generator and reflex-web. Some kwargs (that were moved) accept literals or vars. Maybe in this case it might be worth specifying the typing of these model fields to accept both literals and vars
There was a problem hiding this comment.
Example rx.list where items can be an iterable or a var containing an iterable so an appropriate typing here might be
items: Optional[Union[Iterable, Var[Iterable]]] = None
use regular model fields where necessary
Co-authored-by: Masen Furer <m_github@0x26.net>
Defines/Moves
createmethod args where possible in components as props so reflex-web can discover them