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 was archived by the owner on Jul 17, 2024. It is now read-only.
A crucial feature of a form library is styling support, the user should be able to tweak almost anything about the form with as little effort as possible. Ideas:
Creating cells inside sections (like in SelectableSection) is a problem, as the caller has no control of the cells. We could provide a builder: (ItemType) -> FormCell<Model>, or maybe a method to override? (There’s already cellForItem, but it’s private.) How about the important cell customizations like calling didSelect or setting shouldHighlight – could we do this after the customized builder? Or shall we leave that to the caller?
FormTextFieldCell has to be more customizable. We could at least support several cell styles (ie. a field with a label), but it should also be possible to clear the default constraints and introduce custom ones. So maybe introduce an enum CellStyle { foo, bar, custom } where .custom would not introduce any constraints?
Should we also support binding to model with closures instead of key paths? Ie. read: (Model) -> T, write: (inout Model) -> Void, where keypaths would be just a convenience feature atop of that.
A crucial feature of a form library is styling support, the user should be able to tweak almost anything about the form with as little effort as possible. Ideas:
Creating cells inside sections (like in
SelectableSection) is a problem, as the caller has no control of the cells. We could provide abuilder: (ItemType) -> FormCell<Model>, or maybe a method to override? (There’s alreadycellForItem, but it’s private.) How about the important cell customizations like callingdidSelector settingshouldHighlight– could we do this after the customized builder? Or shall we leave that to the caller?FormTextFieldCellhas to be more customizable. We could at least support several cell styles (ie. a field with a label), but it should also be possible to clear the default constraints and introduce custom ones. So maybe introduce anenum CellStyle { foo, bar, custom }where.customwould not introduce any constraints?Should we also support binding to model with closures instead of key paths? Ie.
read: (Model) -> T,write: (inout Model) -> Void, where keypaths would be just a convenience feature atop of that.