[Chore/#134] Orbit-MVI 라이브러리 버전을 업데이트 합니다. (v6.1.0 -> v10.0.0)

[wjdrjs00]

[ PR Content ]

orbit-mvi 라이브러리 버전 업 작업을 진행했습니다. (v6.1 -> v10.0)

주요 변경사항은 다음과 같습니다.

• intent {}에서 사용중이던 runBlocking이 제거되었습니다 -> pr 링크
• SimpleSyntax -> Syntax 로 마이그레이션 되었습니다.
• 이외 자세한 사항은 해당 링크를 참고하면 좋을거 같습니다. -> 릴리즈 링크

Related issue

• closed [CHORE] Orbit-MVI 버전 업(v6.1.0 -> v10.0.0) 작업을 진행합니다. #134

Work Description

• 버전 업 변경사항 대응

To Reviewers 📢

[추상화에 대한 고찰: orbit MVI의 장점을 활용하지 못하고 있는 이유]
이번 작업을 진행하면서 저희 프로젝트의 orbit mvi 사용 방식에 대해 고민을 해봤습니다.

저희는 mvi 패턴의 "상태 변경 추적의 용이성"의 이점을 누리되, "보일러플레이트 코드 생성"이란 단점을 최소화하기 위해 orbit mvi를 도입했습니다.
하지만 프로젝트의 완성도가 높아진 현시점에서 "과연 보일러플레이트가 줄었는가?"를 생각했을때, 아니다란 생각이 들었습니다. 실제로 수동으로 mvi 패턴을 구현했던 이전 경험과 비교해봐도 orbit을 사용한 코드가 더 간결하다고 느끼기 어려웠습니다.
원인이 무엇일까? 파악을 해봤는데, 저희는 orbit이 제공하는 intent {}를 직접 사용하는 것이 아니라, 초기에 라이브러리 교체 용이성을 목적으로 만든 별도의 추상화 계층(MVIViewModel, sendIntent)을 한 단계 더 통과하고 있습니다. 이 과정에서 intent 객체를 추가로 생성하고 있기 때문에 orbit에서 제거한 보일러플레이트가 다시 발생하고 있었습니다.
이에 대한 해결책을 고민해봤을때, 가능성이 낮은 미래를 고려한 추상화 유지하기 보단 현재의 추상화를 걷어내고 orbit의 장점을 극대화하는 것이 더 얻을 수 있는 이점이 많다고 생각했습니다..!
이에 대한 세환님 의견이 궁금합니다! (어푸 여부와 상관없이, 해당 pr에 남겨주셔도 좋고, 스크럼시간에 다뤄도 좋을거 같습니다!)

Summary by CodeRabbit

릴리스 노트

• Chores

  • Orbit 라이브러리 버전을 10.0.0으로 업데이트했습니다.

• Refactor

  • 여러 뷰모델의 Orbit MVI 구문을 최신형으로 일괄 전환했습니다.
  • 관련 임포트와 함수 시그니처를 일관성 있게 정리했습니다.

• Tests

  • MVI 관련 테스트를 최신 구문에 맞춰 업데이트하고 일부 초기 상태 기대를 정리했습니다.

[coderabbitai]

Walkthrough

Orbit MVI 라이브러리를 6.1.0에서 10.0.0으로 업데이트하고, 프로젝트의 Orbit 구문 타입을 SimpleSyntax에서 Syntax로 일괄 전환했습니다. ViewModel들과 관련 테스트의 reduceState/sendSideEffect 확장 수신자 타입과 import들을 변경했습니다.

Changes

코호트 / 파일(들)	변경 요약
라이브러리 버전 업데이트 gradle/libs.versions.toml	orbit 버전 값을 "6.1.0"에서 "10.0.0"으로 변경
공통 MVI 베이스 presentation/src/main/java/.../common/mviviewmodel/MviViewModel.kt	SimpleSyntax → Syntax로 수신자 타입 변경; sendSideEffect·reduceState 확장 시그니처 및 import 업데이트
ViewModel들 (일괄 변경) presentation/src/main/java/com/threegap/bitnagil/presentation/{emotion,guide,home,login,mypage,onboarding,recommendroutine,routinelist,setting,splash,terms,withdrawal,writeroutine}/*ViewModel.kt	각 ViewModel의 override suspend fun SimpleSyntax<..., ...>.reduceState(...) → override suspend fun Syntax<..., ...>.reduceState(...)로 변경; import 업데이트, 내부 로직 미변경
테스트 presentation/src/test/java/.../common/mviviewmodel/MviViewModelTest.kt	테스트의 SimpleSyntax import·수신자 타입을 Syntax로 변경; 테스트 시퀀스 내 초기 상태 기대치 일부 제거

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant UI as UI / Intent
    participant VM as ViewModel
    participant Orbit as Syntax<STATE,SIDE>
    participant StateStore as state store

    UI->>VM: intent()
    VM->>Orbit: reduceState(intent, currentState)
    Note right of Orbit: receiver type changed\n(SimpleSyntax -> Syntax)
    Orbit->>StateStore: emit new STATE? (return)
    Orbit->>VM: postSideEffect(SIDE) or no-op
    VM->>UI: new state / side-effect

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• 주의할 점:
  • MviViewModel.kt의 확장 수신자 변경이 모든 하위 ViewModel에서 일관되게 적용되었는지 확인
  • 빌드 후 Orbit 10.0.0에서의 API 시그니처(추가 변경사항)가 더 없는지 컴파일/런타임 검증 필요
  • 테스트 수정(초기 상태 기대치 제거)이 의도된 결과인지 확인

Poem

🐰 버전 업 고고! 열로 뛰어오르네,
SimpleSyntax 안녕, Syntax 안아주네.
뷰모델들 줄지어 손잡고,
작고 빠른 변화 춤추듯 지나가네.
당근 한 입, 빌드 성공을 기원해! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	PR 제목은 "[Chore/#134] Orbit-MVI 라이브러리 버전을 업데이트 합니다. (v6.1.0 -> v10.0.0)"로, Orbit-MVI 라이브러리를 v6.1.0에서 v10.0.0으로 업그레이드하는 작업의 핵심 변경사항을 명확하고 구체적으로 나타냅니다. 제목은 간결하고 가독성이 좋으며, 특정 이슈 번호(#134)와 정확한 버전 범위를 포함하여 팀원이 변경사항을 쉽게 파악할 수 있습니다. 실제 변경사항(라이브러리 버전 업그레이드 및 SimpleSyntax에서 Syntax로의 마이그레이션)과 제목이 완벽하게 일치합니다.
Out of Scope Changes Check	✅ Passed	모든 변경사항이 이슈 #134의 범위 내에 있습니다. gradle/libs.versions.toml의 버전 업그레이드와 모든 ViewModel 파일의 SimpleSyntax에서 Syntax로의 마이그레이션, 그리고 테스트 파일 업데이트는 모두 Orbit-MVI 라이브러리 버전 업에 따른 필수 변경사항입니다. MviViewModelTest.kt에서 초기 공상태에 대한 예상값 제거도 새 라이브러리 버전의 동작에 맞추기 위한 테스트 수정으로 범위 내의 변경사항으로 판단됩니다. 비즈니스 로직이나 기능에 영향을 주는 추가적인 변경은 발견되지 않습니다.
Description Check	✅ Passed	PR 설명은 제공된 템플릿의 주요 섹션을 모두 포함합니다. "Related issue"에서 #134를 명시하였고, "Work Description"에서 "버전 업 변경사항 대응"으로 작업 내용을 기술했으며, "To Reviewers" 섹션에서 상세한 기술적 고찰과 함께 팀원의 의견을 요청하고 있습니다. 라이브러리 버전 업의 주요 변경사항(runBlocking 제거, SimpleSyntax → Syntax 마이그레이션)도 명확히 설명되어 있으며, 관련 레퍼런스 링크도 제공되어 있습니다. 보충 설명이나 스크린샷이 필요하지 않은 코드 유지보수 작업이므로 현재 수준의 설명이 적절합니다.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/#134-update-orbit-mvi-v10.0.0

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1b707be and 4ddb0d7.

📒 Files selected for processing (1)

• presentation/src/test/java/com/threegap/bitnagil/presentation/common/mviviewmodel/MviViewModelTest.kt (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🔇 Additional comments (2)

presentation/src/test/java/com/threegap/bitnagil/presentation/common/mviviewmodel/MviViewModelTest.kt (2)

9-9: 올바른 마이그레이션입니다.

Orbit MVI v10.0.0 업데이트에 따라 SimpleSyntax에서 Syntax로 변경된 import가 정확하게 반영되었습니다.

---

57-71: 마이그레이션이 완벽하게 완료되었습니다.

검증 결과 코드베이스 전체에서 다음을 확인했습니다:

• SimpleSyntax 사용 없음 (0 결과)
• 15개 파일에서 모두 org.orbitmvi.orbit.syntax.Syntax 정상 import
• 모든 reduceState 함수가 새로운 Syntax<...> receiver 타입으로 통일됨

MviViewModelTest.kt의 변경사항은 코드베이스 전체 마이그레이션의 일부이며, 모든 ViewModel에서 일관되게 적용되었습니다. 승인됩니다.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[l5x5l]

MVIVIewModel을 설계할 떄 고려했던 점 중 하나가 MVI 패턴을 유지하면서 구현 방식을 변경해야 할 때의 용이성을 고려한 부분이 있습니다!
이와 관련하여 Model-View-Intent 구조로 이루어져 있는 MVI 패턴이라면 Intent객체를 생성하여 Intent에 의한 State 변화를 수행하는 것이 필수적이라 생각했습니다
만약 Intent 객체를 생성하는 것 자체가 번거롭다고 느껴진다면 MVI가 적합한지, 아니면 State를 하나로 묶은 일반적인 MVVM 구조가 적합한지에 대해 의논을 해봐야 할 것 같아요!

단순 State를 하나로 묶은 MVVM 구조가 더 적합하다고 판단된다면, 대현님 말씀대로 Intent를 생성하는 것 자체가 불필요하기에, MviViewModel 대신 직접 orbit을 사용하는 방식이 더 적합할 것 같습니다!

[l5x5l]

고생하셨습니다!

[wjdrjs00]

MVIVIewModel을 설계할 떄 고려했던 점 중 하나가 MVI 패턴을 유지하면서 구현 방식을 변경해야 할 때의 용이성을 고려한 부분이 있습니다! 이와 관련하여 Model-View-Intent 구조로 이루어져 있는 MVI 패턴이라면 Intent객체를 생성하여 Intent에 의한 State 변화를 수행하는 것이 필수적이라 생각했습니다 만약 Intent 객체를 생성하는 것 자체가 번거롭다고 느껴진다면 MVI가 적합한지, 아니면 State를 하나로 묶은 일반적인 MVVM 구조가 적합한지에 대해 의논을 해봐야 할 것 같아요!

단순 State를 하나로 묶은 MVVM 구조가 더 적합하다고 판단된다면, 대현님 말씀대로 Intent를 생성하는 것 자체가 불필요하기에, MviViewModel 대신 직접 orbit을 사용하는 방식이 더 적합할 것 같습니다!

넵! 이 부분은 이번주 스크럼에서 더 자세하게 논의 해봅시다욤~

[easyhooon]

오 runBlocking이 제거되었군요 🔥 🔥 🔥