틈틈히 적어보는 개발 일기

⚠️요약 아래 Flow는 VC의 Bind(reactor: )에서 - View의 Input(Action)을 Reactor와 연결 - View의 Output(State)을 Reactor와 연결 1. UI의 Input을 Reactor.Action.— 로 mapping 후 reactor.action에 bind를 걸어 input 수행 ㄴ 1-1(내부 Flow). 정의된 mutate함수 수행 결과(Observable)를 reduce 함수로 전달, reduce 함수가 state를 변화시킴 2. reactor.state를 UI에 bind를 걸어 output 수행 // MARK: - Code // 1. Action rx.viewWillAppear .mapToVoid() .map { Reactor.Action.fetch ..

⚠️ Binder 💡 왜 UIKit(RxCocoa).rx.text를 변경하는건 MainThread를 지정안해줘도 UI 에러가 뜨지 않는걸까?! → Binder로 래핑된 객체는 Bind가 MainThread에서 동작함을 보장함!!! 그래서 쓰레드를 지정해주거나 Drive를 걸지 않아도 에러가 나오지 않는 것

import Foundation // Node = (index, value) typealias Node = (Int, Int) struct MaxHeap { private var nodes: [Int] = [-1] func print() { var from = 1 var to = 2 while to Int? { if nodes.count == 1 { return nil } nodes.swapAt(1, nodes..

이전에 프로젝트를 진행하며 클로저 내부에서 self를 활용해야 했을 때 이 코드를 정말 자주 습관적으로 사용했다. { [weak self] _ in } guard let self = self else { return } 클로저 내부에서의 캡쳐링으로 인한 강한 참조를 방지하기 위해 `[weak self]`를 활용하기는 했는데 Optional을 해제하기 위해 저렇게 처리를 하다 보니 문득 이게 맞기는 한건가..? 내가 아무 생각 없이 사용하고 있지는 않는건가..? 라는 생각이 들었었고, 또한 강한 참조에 대해 공부할 필요를 느꼈다. 자연스럽게 `guard let self = self else { ... }` 를 사용하는 이유, 이에 대한 동작 원리, 그리고 `[weak self]`를 부르지 않고 바로 `se..

기존에 네트워킹을 위한 코드를 작성하면서 일부 중복 코드를 줄이는데에는 어느정도 성공했었다. 그러나 네트워킹 요구사항이 많아지거나 활용하는 기능들이 많아질수록 필요한 매개변수들이 많아졌다. // 기존 네트워킹 코드 func request(httpMethod: HttpMethod, endPoint: EndPoint, uri: String? = nil, params: [(String, String)] = [], type: T.Type, completion: @escaping(Result) -> Void) { // URLSession dataTask ... } 이렇게 API를 호출함에 있어 필요한 파라미터, 헤더 등등이 늘어날수록 `networkRequest` 메소드에 추가해야 할 파라미터도 늘어났고, 또한 ..

Swift에는 없는 자료구조인 queue와 deque를 O(1)로 어떻게 구현할까? 에 대한 질문을 받아서 확실한 대답이 아닌 추측으로 대답했는데 반은 맞은 것 같다. reversed()의 시간 복잡도가 O(1)임을 알고 있었는데, 이를 통해서 queue와 deque를 구현할 수 있지 않을까 생각했었다. 그래서 살펴보니 reversed()의 리턴 타입이 ReversedCollection 였었고, 이 ReversedColleciton을 다시 살펴보니 BidirectionalCollection 프로토콜이 채택되어 있었고 이를 다시 살펴보니 원하는 결과를 얻었다. BidirectionalColleciton이 단어 뜻 그대로 양방향콜렉션인데 index가 움직일 때마다 반대쪽에 위치하는 index도 동일하게 움직..