Open eteeselink opened 8 years ago
@gcanti i'm still pretty interested to code this up, but i strongly value your opinion. I'd like to know if this has any chance of getting merged in.
Do you think monkey patching a type that way (i.e. adding a tcombFormOptions
field to an type object) is a nice approach? Does it match your design ideas behind tcomb (form)?
First off, tcomb-form is awesome. Thanks!
I currently have the use case where tcomb-form uses types written solely to support form generation, i.e. the same types aren't used elsewhere (the data is otherwise managed in non-JS code). I suspect this is not an uncommon use case.
The code has quite some struct nesting, and looks like this:
It's easy to lose track of things in such an
options
object. It would be more natural for the reader of this code if I could writeThe idea would be that tcomb-form merges the
tcombFormOptions
field with the correct subobject in theoptions
prop toForm
, where the latter overwrites the first. This way you can document static stuff, like help and error texts, right with the data definition, while still keeping all the dynamism that makes tcomb-form awesome.Basically, I understand and strongly support the architectural choice of separating the tcomb types and their tcomb-form configuration, but it some cases this separation is less useful than others. Given that there's already support for
getTcombFormFactory
, this might be a reasonable suggestion to get the best of both worlds?I'd be happy to code the PR if you'd like.