- This topic has 11개 답변, 7명 참여, and was last updated 4 years, 1 month 전에 by
.
-
글
-
-
ReactorKit 에 대한 공부중!
기존 MVVM + Rx 와 차이에 대해 생각해보면, 기존 MVVM은 템플릿이 없어서 개발자들이 이해하는 MVVM의 모양이 다르고, 구현하는 방법도 달랐다는 점이다.
ReactorKit은 제약이 둠으로써, MVVM의 모양을 좀 더 템플릿화해서 사용할 수 있었다.-
Action
- View로부터 Reactor에게 전달된 액션
ex) 보통 유저의 인터렉션과 매칭된다.
- View로부터 Reactor에게 전달된 액션
-
State
- View의 상태를 가지고있는 객체
- View의 UI 컴포넌트와 바인딩된다.
-
Mutation
- ViewModel 내에서 State를 수정하라는 명령을 전달하기위한 객체
Observable<Action>
↓ transform – action combine
Observable<Action>↘︎
Action↓ mutate – ex) updateQuery → setQuery + setRepo
Observable<Mutation>↓ transform – mutation combine
Observable<Mutation>↘︎
Mutationreduce 새로운 상태 생성 후 스트리밍
State ←→ State
-
-
와우 이런걸 공부하셨군요
정말 대단합니댜 -
오호~
-
리액터킷 너무 나이스해요 꼭 써보세여!
-
-
Spring Reactor 생각했는데….
-
멋지십니다.~
스터디 하시면서 .. Flux (https://facebook.github.io/flux/) 에 대해서도
기술 서치 해보시면 좋아요. -
아따 열공하네예 부엉님
-
열공의 산물… 멋집니다!
-
print("Hello World!")
-
-
근데 정확히 어떤면에서 좋은걸 느꼈는지 알려주실 수 있어요?
나이스한 지점이 어떤건지도 궁금해요~
-
View에서는 UI에서의 인터렉션을 Reactor에게 Action을 전달하고
Reactor의 State와 UI컴포넌트를 바인딩만 해두면 되어서 View의 로직이 거의 없고
View에서 Action을 흘려보내면 그에 해당하는 State가 바뀌는 형태로, 흐름 을 추적하기 쉽다고 느꼇어요. 그래서 버그를 추적하기도 쉽구요.
MVVM을 구현하는 사람들마다 다른 모양을 띠는데, 이게 템플릿화 되어서, 많은 사람들이 비슷한 형태로 구현한다는 점에서 이해하기도 좋았어요.
또 Action -> 결과적으로는 Obseravble<State>의 형태로 변환되는데,
Action이 search 버튼을 누르는 거라면
isLoading = true인 State 그 후 isLoading = false, response들을 가진 State 가 반환되어
하나의 Action에서 State의 Sequence를 반환한다는 점에서 Rx의 장점도 잘 가져간다고 생각해서? 좋다고 느꼈어요.
-
-
자세한 답변 감사합니다
새로 나온 SwiftUI랑 Combine을 배우는 거랑 어떤 차이가 있을까요? 비슷한 컨셉 아닌가요?
-
- 답변은 로그인 후 가능합니다.
