A couple of months ago I requested some feedback about a form API idea/proposal (thank you again for that!). After working on it these past two months with @russelldavies and @larribas, I just published the first version of composable-form!
composable-form aims to streamline form handling in Elm by treating forms as functions that take the values of the form as input and return the fields and the result of the form as output.
I am sure there are still many rough edges that need polishing (especially when dealing with custom fields and custom form renderers). So if you try it, I would like to know! Feel free to give me any feedback here, in the repository or over the Elm Slack (@hecrj).
This looks “awesome complete” to me. I feel like this is the rails simple_form for Elm. Thank you for awesome works! Can’t wait to try this package for my next project.
I gave composable-form a try today. I wanted to have a small form containing a textfield, a radio field and a submit button.
Here is my feedback: Based on the examples I got quickly an integrated, working form. Afterwards I wanted to style the output. I have to follow style specs for this example and there are provided styles based on given classes (sometimes depending a specific element structure). I’m using elm-css and inline styles. I found this issue about styling. If I understand correctly, the way is to implement a custom renderer. This sounds interesting, and is probably worth the effort, if there is a lot of reuse. I didn’t dig deeper for now, because of time constraints. My impression is the custom renderer has to implement a bunch of internal components.
I was also wondering if there is no way to add some css styles or class names with the current api. Is this the case or did I skip over it when reading the documentation? If so, it could be an option to provide an easy way to add styles.
composable-form is not really meant to help you render forms. In the end, I think that everyone has different needs when it comes to form rendering, so trying to come up with an abstraction for that is very hard.
The provided Form.View.asHtml renderer produces a very simple HTML structure with some hardcoded classes. It is meant to be a basic default for simple use cases and to try out the API.
You have 2 different options to create a custom renderer:
Use Form.View.custom to write a renderer that outputs Html.Styled.Html using elm-css.
Write your own renderer from scratch using Form.fill.
With (1) you will define a set of functions that render each type of field using elm-css and you will get a renderer that can be used like Form.View.asHtml.
With (2) you are entirely free to implement your renderer without depending on the Form.View API (i.e., no need to use Form.View.Model, etc.).
I do not think there is a way to create a default form renderer that is abstract enough to keep everyone happy.
So, the idea right now is to keep Form.View.asHtml simple and encourage people to write their own custom renderer when they have special needs. In the end, a renderer is just view code that you would have written if you were not using composable-form anyways. The difference is that composable-form forces you to make the form view code reusable, so you only need to write it once to render all your forms!