State 와 Event 분리 #147
State 와 Event 분리 #147
Conversation
ui 모듈과 util 모듈을 분리, 다른 모듈들에서 공통으로 사용하는 ui와 관련되지 않는 함수 및 클래스를 모아둠 패키지 구조 변경-> 확장함수가 아닌 파일들은 extension 밖으로 꺼냄
Event 를 핸들링 하기 위함
뷰에서 사용자의 액션을 직접 처리하는 것은 MVVM 패턴에 위배, style check success
easyhooon
added
feature
공식 문서에 의하면 modifier 의 위치는 first 'optional' parameter 임, first parameter 가 아니라
| package com.nexters.bandalart.android.core.network.di | ||
|
|
||
| import javax.inject.Qualifier | ||
|
|
There was a problem hiding this comment.
소규모 프로젝트에서는 쓸일이 없는가 싶다가도 이럴 때 한번씩 나온단 말이지 ㄷㄷ
There was a problem hiding this comment.
@nAmed Annotation -> @qualifier Annotation 으로 변경
저거 왜 commit name이 @nAmed 로 안되어있고 @nAmed 로 되어있지.. 무튼 하드 코딩으로 provider 를 분류하는게 안정성 면에서 별로인것 같다는 생각이 들어
There was a problem hiding this comment.
아 @ 뒤에 바로 대문자를 쓰면 저렇게 변하나보네 @ Named로 써도 그러네
| color: Color, | ||
| fontSize: TextUnit, | ||
| fontWeight: FontWeight, | ||
| modifier: Modifier = Modifier, |
There was a problem hiding this comment.
내가 예전에 작업할때 해당 문서를 참고해서 modifier 를 최상단 파라미터로 올렸었는데, 문서를 내가 잘 못 이해 했던거 였음
modifier 는 first 'optional' paramter 여야 한다는 것인데, 이게 optional 의 의미가 만약에 함수를 사용할 때 해당 파라미터를 명시하지 않을 경우 default value로 선언된 값이 적용되는 파라미터들을 의미 하는데
일반적으로 Kotlin 함수의 매개변수는 default value가 없는 것들이 먼저 오고, 그 뒤에 default value가 있는 매개변수가 와야 합니다(Trailing lambda는 예외). Composable도 마찬가지로 default value가 없는 것, Modifier, default value가 있는 것 순서대로 와야 합니다.
와 같이 default value가 없는, 반드시 함수를 사용할 때 해당 파라미터를 명시해줘야하는 것들 다음에 modifier를 선언해주는 것을 권장하드라구
…state-event # Conflicts: # feature/home/src/main/kotlin/com/nexters/bandalart/android/feature/home/BandalartBottomSheet.kt
필요 없는 import 제거
ViewModel 에서 사용자의 액션을 처리하고, 이벤트를 View 에 전달하는 방식으로 변경
-> MVVM 패턴에 적합
core:util 모듈 추가
-> 공통으로 사용되는 함수 및 클래스들 중 ui 와 관련 없는, Compose 의존성이 없는 파일들을 util 로 분리
UiText 클래스 보완
-> 변수가 포함된 String resource 를 핸들링 하기 위함