Struct support feature
What if we wanted a nested struct---whose fields are still s/i/b primitives, or other of such structs---to be stored within a form?
I imagine when interacting with these fields, they unravel an indented "subform" (consider a dropdown), if not already unraveled on first render. Here's a mock example that allows users to build out a config for a CLI client:
[ Use Vim Keys ] true
>> [------URL------]
[ Protocol ]: HTTP
[ Host ]: localhost
>> [ Port ]: 8080|
[ ISO 4217 Code ]: USD
Slice support feature
Furthermore, support for slice-based fields could greatly compound this feature's potential. I'll go on to cover that here and split these into related sub-issues; realistically, slice support probably comes first before adding any struct support.
Currently, no support exists for managing slices of the s/i/b primitive fields. A slice could render a + to indicate that users may add another entry. The render may appear something like so:
[ Full Name ] Johnny Doughboy
[ Phone Number ] 123-555-6789
>> [ Your favorite movies ]
>> [ 1 ] Birdemic: Shock and Terror|
[ + ] ------------------------------------------
[ Travel ]
Support for slice of struct type
Here's what it could look like for both features to be made compatible with one another:
[ Full Name ] Johnny Doughboy
[ Phone Number ] 123-555-6789
>> [ Work Experience ]
[ 1 ] -----------------------------------------
[ Company Name ]: Joe Schmoe\'s BBQ
[ Company Address ]: 1234 joeschmoe lane, Fake City, NA
> [ + ] ------------------------------------------
[ Travel ]: true
After selecting [ + ]:
[ Full Name ] Johnny Doughboy
[ Phone Number ] 123-555-6789
>> [ Work Experience ]
[ 1 ] -----------------------------------------
[ Company Name ]: Joe Schmoe\'s BBQ
[ Company Address ]: 1234 joeschmoe lane, Fake City, NA
>> [ 2 ] ------------------------------------------
>> [ Company Name ]: |
[ Company Address ]:
[ + ] -----------------------------------------
[ Travel ]
Other notes / conclusion
- One or both of these features will warrant additional "sub-cursors", scoped to just the struct or slice, as users navigate over and edit their related fields.
- I imagine that when selecting a struct (or in the case of slices, after selecting
[ + ]) , the empty entry is selected immediately for user input (as illustrated above). With slices, if and only if no entries exist yet, the first new element ought to be automatically created and select as soon as the slice is first selected.
- Slices ought to render their
[ + ] entry indicator only while the greater slice field itself is selected.
This all may open up great opportunities. Or it may simply add more overhead with the reflect package that is more consequential to performance than makes the work worth it; I am not entirely sure as of writing this.
Struct support feature
What if we wanted a nested struct---whose fields are still s/i/b primitives, or other of such structs---to be stored within a form?
I imagine when interacting with these fields, they unravel an indented "subform" (consider a dropdown), if not already unraveled on first render. Here's a mock example that allows users to build out a config for a CLI client:
Slice support feature
Furthermore, support for slice-based fields could greatly compound this feature's potential. I'll go on to cover that here and split these into related sub-issues; realistically, slice support probably comes first before adding any struct support.
Currently, no support exists for managing slices of the s/i/b primitive fields. A slice could render a
+to indicate that users may add another entry. The render may appear something like so:Support for slice of struct type
Here's what it could look like for both features to be made compatible with one another:
After selecting
[ + ]:Other notes / conclusion
[ + ]) , the empty entry is selected immediately for user input (as illustrated above). With slices, if and only if no entries exist yet, the first new element ought to be automatically created and select as soon as the slice is first selected.[ + ]entry indicator only while the greater slice field itself is selected.This all may open up great opportunities. Or it may simply add more overhead with the
reflectpackage that is more consequential to performance than makes the work worth it; I am not entirely sure as of writing this.