refactor(ios): extract the text-entry engine into RunnerTests+TextEntry.swift#651
Merged
Merged
Conversation
Size Report
Startup median (7 runs, lower is better):
Top changed chunks: no changes in the largest emitted chunks. |
…ry.swift Behavior-preserving relocation: move the text-entry concern out of the (formerly 1805-line) RunnerTests+Interaction.swift — the repo's most-changed file — into a new RunnerTests+TextEntry.swift. Interaction.swift drops to 1068 lines (-737). Moved verbatim (no logic changes): - value types: TextTypingRepairMode, TextEntryTiming, TextEntryResult, TextEntryTarget - the focus -> type -> verify -> repair pipeline (typeTextReliably + focus orchestration + readiness polling + dropped-char/repair heuristics) - clearTextInput and the text-entry leaf helpers (editableTextValue, isPlaceholderValue, isGenericTextInputLabel, normalizedElementText, moveCaretToEnd, estimatedDeleteCount, keyboardBecameVisible, keyboardElementExists) The whole cluster is text-entry-exclusive (its only callers are within the moved code or the already-internal command entry points), so every symbol keeps its original visibility — no access widened. Shared helpers used by gestures/snapshot/get-text (isKeyboardVisible, visibleKeyboardFrame, textInputAt, textInputCandidatesAt, readableText, ...) stay in Interaction. The new file is auto-included via the project's file-system-synchronized group. This is the safe, cosmetic half of the "TextEntry engine" architecture candidate. A deeper extraction behind a real seam/type is intentionally deferred: it carries the #245 revert risk and wants stronger text-entry e2e coverage first. Verified: xcodebuild build-for-testing -> TEST BUILD SUCCEEDED. Pure relocation, no behavior change.
thymikee
force-pushed
the
refactor/ios-runner-textentry-file
branch
from
9a71b14 to
7ffc56d
Compare
Member
Author
|
Both findings were stale-base artifacts, not real changes — thanks for catching it. The branch was 2 commits behind
My branch never touched Rebased onto latest |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Behavior-preserving file split: move the text-entry concern out of
RunnerTests+Interaction.swift(the repo's most-changed file, formerly 1805 lines) into a newRunnerTests+TextEntry.swift. Interaction.swift drops to 1068 lines (−737).Moved verbatim — no logic changes:
TextTypingRepairMode,TextEntryTiming,TextEntryResult,TextEntryTarget)typeTextReliably+ focus orchestration + readiness polling + dropped-char/repair heuristics)clearTextInputand the text-entry leaf helpers (editableTextValue,isPlaceholderValue,isGenericTextInputLabel,normalizedElementText,moveCaretToEnd,estimatedDeleteCount,keyboardBecameVisible,keyboardElementExists)Why
Interaction.swiftmixed five unrelated concerns; text entry alone was >half of it. Splitting it out is the biggest single navigability/token win in the file, with no behavioral surface.Safety
internalcommand entry points (typeTextReliably,focusTextInputForTextEntry,resolveTextEntryMode,isTextEntryElement,waitForTextEntryReadinessAfterTap). The file-local leaf helpers stayprivate.Interaction.swift(used by gestures/snapshot/get-text):isKeyboardVisible,visibleKeyboardFrame,textInputAt,textInputCandidatesAt,readableText,prefersExpandedTextRead,findScopeElement.pbxprojedit).xcodebuild build-for-testing→TEST BUILD SUCCEEDED. Behavior is unchanged by construction (pure move); text entry is exercised by the existing04-text-input-keyboard.adsmoke replay.Scope
This is the safe, cosmetic half of the "TextEntry engine" architecture candidate. A deeper extraction (a real
TextEntrytype behind a seam, making the pipeline unit-testable) is intentionally deferred — it carries the #245 interaction-handler-revert risk and wants stronger text-entry e2e coverage first.