FancyForms

FancyForms is a library for building forms in Elm. It is designed with the following goals in mind:

1. Type saftey: Data collected in the forms will be returned directly into a user provided type.
2. Ease of use: No matter how complex the form is, it will only need one Msg and one field on the model.
3. Customization: Users can provide their own widgets and custom validations.
4. CSS Agnostic: Adapts to any CSS framework.
5. Composable: Smaller forms can be combined into larger forms.
6. I18n: Internationalization is supported by avoiding hard coded strings.

🚧 Work in progress 🚧

The library is still under active development and is still missing some features to be production ready.

Checklist:

• Type saftey
• Custom widget support
• Form can be initialized with custom values
• Validation errors aggregate to the top
• Lists fields:
  • Any widget can be used as list item
  • User can add and remove list items
  • User can reorder list items
  • User can add list item at specified index
• Variant fields:
  • Widget to select variant can be specified
  • Any widget can be used as variant input

Documentation

I have not invested heavily into the Package Docs yet. But there are some detailed examples with explanations in the dedicated docs

https://blog.axelerator.de/fancy-forms/

Decisions

Focus on extendability

The API is heavily inspired by dillonkearns/elm-form 🙏 But contrary to elm-form I did not aim for compatibilty with elm-pages and lamdera. So I do blatanlty store functions in the Model for example.

List (Html msg) over Html msg as return type

Functions that return List (Html msg) are more composable. Specifically when nesting the "wrapping" component can decide whether to concatenate the list or not.

This allows for more flexibility in the markup to for example account for markup required by certain CSS frameworks like Bootstrap.

Instead of having labels and errors in different containers they can all live next to each other.

Custom error type

Having to proivde a custom error type might seem like it adds unnecessary complexity. The primary motivation is to allow to keep error messages translatable without having to draw the translation logic into the form library (or the form logic in the application).