Open
Conversation
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
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.
About this PR
🔖 Related Issue
📚 Contents
배경 (Before)
초기 요구사항은 “입력 중에도 즉시 이모지 변환이 반영되는 UX” 였습니다.
다만 출시 일정 내에 이를 그대로 구현하려면, 한글 IME 조합(입력 중
marked text) 상태까지 포함해 실시간 치환을 안정적으로 처리해야 했고, 그 과정에서가 빠르게 커질 수 있다고 판단했습니다.
그래서 출시를 우선 맞추기 위해, 당시 가능한 안정적인 대안으로 변환 확정 타이밍을
띄어쓰기/줄바꿈같은 경계 입력 시점으로 제안/적용했습니다.출시 이후에는 원래 요구 UX(입력 중 반응성)를 달성하기 위해, IME 안정성과 UX를 함께 만족시키는 “실시간 반영 방식” 을 다시 설계했고, 그 결과가 이번 PR입니다. (with AI 🤖)
구현 방식 고민 (How)
이번 변경의 핵심 질문은 “무엇을 즉시 반영하고, 무엇을 보류할 것인가” 였습니다.
바→ 받침/쌍자음 조합 가능) 상태는 아직 확정이 아니기 때문에, 조합 중간에 치환이 들어가면 의도한 완성 글자 인지가 어려워지고 입력 흐름이 불안정해질 수 있습니다.현재 입력 중 1글자(또는 marked 구간)는 보류하고,직전 확정(confirmed) 텍스트부터 반영으로 잡았습니다.final snapshot으로 flush합니다.즉, 이번 PR에서 말하는 “실시간”은 무조건 즉시 치환이 아니라, 입력 엔진 안정성과 UX 반응성을 함께 만족시키는 반영 타이밍 제어로 구현했습니다.
아키텍처 고민 (Why this boundary)
초기에는 MVI를 단순하게 해석해 입력 관련 상태를 Store에 최대한 올리려 했습니다.
하지만 입력 도메인에서는 View도 입력 상태를 알아야 하는데, 중간값까지 Store로 올리면 Store와 View가 동일/유사 상태를 동시에 보유하게 되고, 결과적으로 실시간 동기화 코드가 비대해지는 문제가 발생했습니다.
그래서 상태를 아래 기준으로 분리했습니다.
UITextView생명주기에 묶인 입력 진행 상태(IME marked/unmarked, 커서/부분 치환 과정 등): InputView(Coordinator) 로컬 소유final snapshot이벤트로 경계 전달결론적으로 MVI를 버린 것이 아니라, 입력 엔진 진행 상태와 도메인 정책/저장 트랜잭션 상태의 책임 경계를 명확히 분리한 변경입니다.
최종 구조 (After)
Store(정책/트랜잭션) -> MemoView(중재) -> InputView(입력/IME/변환 처리)isInputEmpty,savePhase등 정책 상태와 저장 트랜잭션을 담당합니다.final snapshot(원문/이모지 포함)을 만들어 경계로 전달합니다.주요 변경 사항
MemoInputSeedMemoInputSnapshotMemoInputUICommandMemoInputUIEventinputSeed,isEmojiPresentationEnabled,uiCommandEventonDraftAvailabilityChanged,onFinalSnapshotReady,onFinalSnapshotFailedMemoView가 Store side effect와 Input 이벤트를 연결검증
아래 테스트/시나리오를 통해 회귀를 확인했습니다.
saveTappedTwiceBeforeFinalSyncEmitsSingleRequestemptyFinalSnapshotDoesNotPersistfinalSyncCompletedWithMismatchedRequestIDDoesNotPersistfinalSyncFailedMatchingRequestIDReturnsIdlefinalSyncFailedWithMismatchedRequestIDIsIgnored📸 Screenshot
Other information 🔥
리뷰 포인트