InputField improvement suggestions

[vaIerika]

1. Next field logic isn't adjustable

• Right now, the logic skips valid fields and jumps to the next invalid one. I am not sure if this behavior matches the design and works for every project.
• You cannot change this behavior, even with a native modifier .focused(_:equals:), because Coordinator callbacks in InputField make it trick to override.

2. Validation change doesn't affect UI without changes in input values

• Calling validityGroup.validateAll() doesn't trigger UI updates.
• Things like the red border or hint message won't show unless updateValidationState() is called, but it is private and only runs on updateUIView().
• This creates an issue: if user doesn't touch the fields (e.g. leaves them empty or with wrong default value) and presses Submit, no error will show.

3. Global appearance for text field

• Why not let us pass appearance as a parameter?
• Correct me if I'm wrong, but it feel like even something simple as change border colors on one screen becomes a challenge. It's pretty common to have fields with different looks in the same app, from design point of view they look fitting, but for us it is different UI settings. It feels unnecessary to have a conversation with designers over minor stuff like border color.

4. Hint is always there

• Hint takes up space in UI even if it's empty or nil.

[plajdo]

Quick reply before I can investigate the issues in code:

• 1 - Next field logic isn't adjustable

  • That (the logic you are describing) shouldn't be the case, either it's a bug you found, or something weird is going on in iOS 18
  • You are right, it's hard to override and customise, definitely an area of potential improvement

• 2 - Validation change doesn't affect UI without changes in input values

  • This is a discord in the ways we do validation of text input in our apps.
  • Basically, there are two UX-equivalent ways of doing things:
    • Buttons are enabled when input is correct, input is validated on loss of focus (this behaviour is accounted for and implemented, validation logic is based on this assumption)
    • Buttons are always enabled, input is validated when buttons are tapped (not implemented, but can be worked around)

• 3 - Global appearance for text field

  • Indeed, multiple different text field styles on one screen are impossible to do; multiple different text field styles in app (on different screens) are doable, but a very unpleasant experience
  • There are plans in the future to support "SwiftUI-native" way of styling (eg. through an .inputFieldStyle() modifier)
  • Currently not very high-priority, it has always been easier to just ping the designer to change the design in Figma file

• 4 - Hint is always there

  • This is correct and expected
  • Hint has been implemented this way to prevent "jumping" (changing height) of text fields when transitioning between normal/error states.
  • When you use text field without "hint" and without error validation, it will shrink as you expect.
  • We could add a way to change the default behaviour, if this should cause issues in the future

[vaIerika]

PR to address the 3rd issue: #15

[plajdo]

Note:
1st issue will probably be dismissed as invalid; did not manage to replicate the issue
2nd issue is addressed in PR #20 (.realtime() validator modifier)