While I agree with the philosophy for most fields, I have to say I believe this is the wrong approach when it comes to add more fields. In every situation where I’ve ever wanted to use an add more field, I’ve needed to allow entry of 0 to infinity items. However, this functionality is currently impossible in Piklist; instead, we can only allow entry of 1 to infinity items. This results in ugly, awkward workarounds because posts that have no items associated with them in reality will always appear to have one item associated with them anyway. But some posts really do have one item associated with them. So when there’s one item associated with a post, we have to add in extra logic to double check whether it’s a real item or not. The fact that we have to check that means we’re getting bad data; and Piklist isn’t just allowing bad data to be entered, it’s forcing bad data to be entered.

In turn, this leads to further complications if the add more is a grouped field (which has usually been the case for my usage). Which fields are absolutely required for an item? You can’t actually make the fields required (since that will break data entry for posts with no items), so you have to expect bad data and then double-check that the required data is really there before displaying it. If any required fields are missing, you have to assume it’s bad data and ignore it. This forces you to effectively make fields secretly required, and when a user fails to fill out one field that was secretly required, they’re going to be mighty confused as to why the item they entered won’t show up on the front end.

Bottom line, add more fields are not like other fields, so forcing a blank entry to be saved when they’re empty causes a ton of problems while providing no real benefit. Add more fields need to support a truly empty, no-items-added state.

Fair enough. I’m definitely looking forward to v1.0 – it’s natural for the API to be a bit of a moving target while it’s in beta, but it will be awesome to have an official stable release to work with, so I understand that being the priority. That said, this issue has probably been the one significant recurring pain point for me in working with Piklist, so I’m glad to hear your team will give it some thought when time allows.