Support reentrant updates

[oscbyspro]

Introduction

DiffableTextField(value: $optional, style: .number.suffix(optional != nil ? “ items” : “”))

Styles such as the one above (that depend on the input/output value) resolve changes between some and none in two steps, and sometimes two frames. While somewhat difficult to notice, it is also difficult to unsee. It is less than ideal and can easily be fixed.

Proposal

When the value changes, wait for it to stabilize before applying any downstream changes.

Alternatives

A) Conditional single-pass modifiers, like nonblankSuffix(_:) (more options/complexity).

[oscbyspro]

Side note: I haven’t tested it outside of Xcode 14 beta 5.

[oscbyspro]

I think reentrance is definitely preferable because it introduces no downstream complexity, whereas special case styles introduce more options, and make it so you have to be aware of edge cases you may do not even have to consider otherwise.

[oscbyspro]

Added in f930ce4 and it’s so much nicer 🤩

[oscbyspro]

On a tangent: checking !update can replace the interaction lock (even the async one!). Who’d a thunk it.

[oscbyspro]

[oscbyspro]

There’s some funky behavior in combination with UITextField’s normal “autocorrection” behavior, when tapping on an inactive field bound to an invalid value (an edge case among edge cases). UIKit may want to select some part of it and offer a suggestion, then the style immediately removes it because it’s invalid. This manifests as a single frame selection flash. diffableTextViews_autocorrectionDisabled() prevents this.

---

I’ll see if I can make it work nicely by default.

---

It’s possible. I’mma need that lock I binned tho. I can't get rid of the suggestion bubble that pops up, but I think that's OK.

---

Fixed in cb8eb65. Reintroduced: Lock to isolate reentrant calls to textFieldDidChangeSelection(_:).

---

Another flash happens whenever you actually accept a suggestion, but it also happens in SwiftUI.TextField and is therefore outside the scope of this project (whatever solution I add would just get rug-pulled by  if/when they fix it).

---

It's possible that the prior fix would also be unnecessary if the latter was fixed by .

[oscbyspro]

There are some minor side effects of reentrant updates. Given:

.number.suffix(amount != nil ? “ items" : “”)

When the value is nil and the user types . the following happens:

0) initial: nil, ""
1) resolve:   0, “0. items”
-- the value is no longer nil so the style changes
2) interpret: 0, “0 items” (separator was removed)

---

It is unrelated to reentrancy and has to do with dynamic styles. Compare:

.number.equals(amount != nil)