As I continue working on Formless, I’d like to continue publicly discussing problems and their solutions, whether it’s straightforward PureScript, library / API design, something Halogen focused, and so on. I hope that others are able to stumble across the discussions and glean some insight from them!
Today, I’m struggling with a library / API design question, and I’m curious to hear from any users of Formless as well as anyone experienced writing PureScript libraries / Halogen components as to what they prefer.
I’ve given it a longer treatment below, but here’s the shortest version of the question:
I have the choice of creating two versions of some type
data X userForm formOutput = ... data X userForm = ...
This type represents the set of form inputs (
userForm) and in an alternate version also represents what type successful form submission is meant to parse to (
In the first case, the user sees both their set of form inputs and the eventual output they want to parse a successful form submission into. In the second case, the user sees only their set of form inputs, which they can then transform into whatever they want after the fact.
The type parameter brings almost no new conveniences to using the library. Its only purpose is to let the library apply your submission function on your behalf rather than just return the form to you. Given that you could just apply the submission once you’ve got the form the benefit there is minimal at best.
But this extra type parameter is interesting for another reason: it lets you know, at a glance, what type this form is going to result in. That might save you from another frustration: digging through your source code to remember what you were going to parse that form into.
My question: given that the type parameter adds almost no functionality to a component using it, but it does add some possibly-useful information at a glance, is it worth the extra complexity of carrying it around and teaching it to beginners?