iOS 개발을 하며 React 의 함수형개발방식이 그냥 옵션일 뿐임을 상기시켜주었다.

이 글에서 언급된 함수형 프로그래밍 방식이 최신의 트렌드인 것으로 생각하였지만 iOS 개발을 하며 잘못됨을 인지.

React 와 함수형 프로그래밍 Functional Programming vs OOP

 

함수형 개발방식은 하나의 옵션일 뿐이다. 위의 글에서 언급된 객체지향개발방식 + 쓰레드 의 문제로 지적한 부분이

객체지향방식으로 개발을 했을 때 추상화를 위해서 메소드를 정의하는데 해당 메소드가 어떤 동작을 하라는 명령형 방식이되고 그럴 경우 해당 명령형 메소드가 동작을 할 때 선점형 방식인 쓰레드에서 동작할 것이고 그럴 경우 어떤 컴포넌트의 state 에 영향을 미칠 때 여러군데에서 부수효과가 발생할 경우 해당 state 에 대해 의도치 않은 오류를 야기할 수 있을 것 같다고 문제 제기를 하였다.

 

하지만 iOS 를 개발하면서 객체지향개발방식 + 쓰레드 로 UI 컴포넌트의 상태와 동작을 다루는 방식에 위와 같은 오류가 생기지 않으면서도 안정적으로 개발될 수 있음을 인지하게 되었다. 그냥 단순히 해당 state 에 atomic 만 붙여주어도 된다. (java 에서는 synchronize 같은) java 의 swing 이나 javaFX 같은 것도 iOS 보다는 못하지만 다 괜찮게 동작한다. 메인쓰레드에서 UI 의 갱신을 관리하며 특정 컴포넌트들은 observable 되고 필요에 따라 능동적으로 갱신되어야 할 경우 DispatchQueue 메인 쓰레드에서 동작하도록 해주거나 하는 등의 방식들을 제공하는데 이것이 훨씬 직관적이고 나은 방식인 것으로 보인다.

https://tech.gc.com/demystifying-ios-layout/

 

물론 state machine 으로서 순차적인 이벤트의 기록과 과거로의 회귀를 통한 디버깅 등의 장점은 취할 수 없지만 충분히 사람 친화적인 논리 중심의 안정적인 개발 방식인 객체지향개발방식 + 쓰레드 가 더 좋아보인다. 물론 때에 따라 필요에 따라 Stream 하게 Reactive 를 넣어주거나 함수형 개발방식을 넣어주어도 될 것. 부가적인 양념일 뿐. 애초에 객체지향과 쓰레드가 더 신기술 아니었던가?

 

그리고 추가적으로 리액트의 함수형 컴포넌트와 훅 방식으로의 전환에 있어 라이프사이클 함수들이 모두 제거되었는데 useEffect 를 통해서 그리고 react naviation 의 경우 useLayoutEffect 와 같은 것을 통해 iOS 의 viewDidLoad, viewWillLoad 같은 라이프사이클 메소드는 가지고 있다고 봐야한다. 확실히 제거된 것은 shouldComponentUpdate 와 같이 UI 업데이트에 영향을 주는 메소드이다. 이것이 완전 함수형 개발방식의 흐름에 방해를 주는 것이었기에 제거된 것이고 나머지 생명주기 함수는 단순화해서 그냥 useEffect 를 통해 다 퉁쳐서 넣은 것. 그런데... 이렇게 단순화하여 퉁친다는 것이 전통적 개발 방식보다 못한 것 같다는 결론이다.