Inflexible Forms

Library Design vs Product Goals

In one of my current projects, the form library of choice is Eureka. It was chosen over the old standard of FXForms because it's in more active development, and it takes advantage of new features in Swift.

After a bit of a learning curve, getting basic forms on screen in pretty easy. Global customization gets a bit repetitive, especially as it can require adding the customization to each variant of a row introduced by generics, like PushRow<String> and PushRow<Int>. Getting a basic form with basic features working becomes a fairly quick task. Some of the advanced features that come in the library are a bit harder to get a handle on, but assuming you're working in alignment with the goals of the library, then everything goes fairly well.

The tricky part comes when you venture into behavior far outside what the Eureka was built for. There's a lot of magic under the hood, which means that sometimes you end up fighting it. It can mean that what seems like an easy tweak to a cell ends up requiring making a custom cell subclass with strange under the hood hacks to get something that's almost but not quite a standard cell.

Increasingly, I want a forms library that does less work for me. If I take managing a complex UI stack out of my forms library it makes the forms library isn't going to fight me on custom UI designs because it isn't strongly opinionated about the UI designs.

The parts of a form library that I want the wiring between a data structure and the input fields, but not to be stuck with every form using a UITableView. I'm starting to think that most forms should be views in a UIStackView, because if I have a single form with enough cells that cell re-use is going to be important, there are probably too many rows in one view controller, or other problems.

After that, it needs to handle implementation details like data formatters, managing the responder chain, and possibly a few more things. I'm not sure where this theoretical library lives on my project queue, but gathering solid minimal requirements is going to be a first step.