Forem: Ingun 전인건

Flux와 List의 Algebra 구조는 같다

Ingun 전인건 — Mon, 30 Mar 2020 11:46:57 +0000

저는 NgRx를 쓰면서 처음 플럭스(Flux)구조를 접했어요. 플럭스의 첫인상은 상당히 복잡해보였죠. 하지만 가만보니 대수구조(algebraic structure)가 리스트(list) 자료구조와 같다는걸 알아챘어요. 그로써 복잡해보이는 구조를 더 간단한 구조로 투영해서 볼 수 있었고 결과적으로 더 쉽고 빠르게 적응할 수 있었어요. 저는 이번 글에서 바로 이 경험을 공유해볼거에요.

글을 읽기 위한 배경 지식

약간의 수학: Group 정도만 아셔도 돼요.
Flux(선택): 마지막에 Flux를 예로 들거라서 아시면 좋아요.

프로그래머에게 Algebra는 무엇인가?

Algebra A 를 만족하는 타입 T의 정의는 "T를 Algebraic하게 생성하는 방법" 을 물어보고, 답을 eval이라는 함수로 옮겨 적는것과 같아요. Group 을 예로 하나 들어볼게요. 그룹의 수학적 정의는 다음과 같아요.

\begin{aligned} &\text{Group } T \\ &\bullet : T \times T \rightarrow T \\ &T^{-1} : T \rightarrow T \\ &id : () \rightarrow T \\ &t_1 \bullet (t_2 \bullet t_3) = (t_1 \bullet t_2) \bullet t_3 \\ &T^{-1} \bullet T = T \bullet T^{-1} \\ &t \bullet id() = id() \bullet t = t \end{aligned}

이제 위에서 말한 질문을 스스로에게 던져보세요. T 를 algebraic하게 생성하는 방법은 뭐가있을까요? 그룹의 정의에 따르면 다음과같은 세가지 방법밖에 없어요.

binary 연산자 $∙:T2→T\bullet : T^2 \rightarrow T$
unary 연산자 $\rightarrow T$
nullary 연산자 $\rightarrow T$

identty 오브젝트를 nullary 함수로 표현한 부분을 주의해주세요. id 의 도메인을 1로 표현한 이유는 타입은 집합이고, 집합의 유일한 identification 은 cardinality(element 의 갯수)이기 때문에 단순히 숫자로 표현하는것에 전혀 문제가 없기 때문이에요.

셋을 piecewise 함수로 합친 $eval: T^2 + T + 1$ 함수가 바로 Algebra의 정의에요.

예로 그룹 Mod 5와 $Z\mathbb{Z}$ (Integers) 를 각각 eval로 정의해볼게요.

Mod N의 eval 과 $Z\mathbb{Z}$ 의 eval의 signature 는 둘다 $T2+T+1→TT^2 + T + 1 \rightarrow T$ 로 그룹이기 때문에 같아요. 하지만 구현은 다른 Algebra이기 때문에 다르죠.

Mod N의 eval 은 $\bullet y$ 을 $x + y$ 의 결과값으로(여기서 + 는 Mod N의 덧셈), $x^{-1}$ 는 $- x$ 의 결과값으로, $1\mathbb{1}$ 는 $0‾\overline{0}$ 으로 맵핑하고 $Z\mathbb{Z}$ 의 eval은 $\bullet y$ 을 $x + y$ 의 결과값으로, $x^{-1}$ 을 $- x$ 의 결과값으로, $1\mathbb{1}$ 를 $0$ 로 맵핑해요.

리스트 Algebra

이제 Algeba에 대해서 조금 알았으니 좀더 실용적으로 접근해봅시다. 프로그래머들이 의식하진 않지만 매일매일 쓰는 Algebra가 하나 있어요. 바로 List E 에요. 어떤 타입 E의 List 도 그룹과 같은 Algebraic 구조에요. List E를 Algebra로 정의하기위해 그룹에서 했던것처럼 다음과같은 질문으로 시작해 볼게요. List E를 어떻게 algebraic 하게 생성할 수 있을까요? 프로그래머들은 List를 정의할때 필수로 다음 두 생성자를 먼저 만들어요.

비어있는 리스트
기존 리스트 에 새로운 e 가 추가된 리스트

이 두 생성자를 operator로 사용해서 위 Group처럼 정의해볼게요.

\begin{aligned} & \text{List E } T \\ & id : \textbf{1} \rightarrow T \\ & \bullet : e \times T \rightarrow T \end{aligned}

여기서 $e$ 는 타입 E의 cardinality 를 뜻하는 상수에요.

첫번째 생성자는 $i d$ 에 해당하고 두번째 생성자는 $∙\bullet$ 에 해당해요. List E에 conform 할 algebra의 eval함수의 signature 는 $\rightarrow T$ 가 되겠죠.

우리는 List E에 conform 하는 두개의 algebra를 만드거에요. 하나는 $i d$ 가 0으로 evaluate되고 $\bullet t$ 는 $1 + t$ 로 evaluate 되게끔 구현하고 Len 이라고 부를거에요. 여기서 E는 어떠한 타입이든 될 수 있고 T는 이미 $i d$ 가 0으로 evaluate 한다는 점에서 Int로 결정된거에요(type inference). 다른 하나는 $i d$ 가 $0_E$ 으로 evaluate되고 $\bullet t$ 는 $e + t$ 로 evaluate 되게끔 구현하고 Sum이라고 부를거에요. 여기서 $0_E$ 의 의미는 타입 E의 0에 해당하는 element를 뜻하고요 마찬가지로 $i d$ 의 결과 타입이 E라는 점에서 이미 T도 E라는 점이 결정이 된거에요.

신기하게도 Sum Algebra의 evaluation은 리스트에 있는 모든 E의 합이되고, Len Algebra의 evaluation은 리스트가 포함하는 element의 갯수 (리스트의 길이)가 돼요. 둘의 eval함수의 구현을 들여다 보고 어떻게 이럴 수 있는지 알아볼게요.

Len의 eval은 다음과 같아요.

eval_{\text{len}}(x) = \begin{cases} 1 + t & \text{if $x = (e, t)$} \\ 0 & \text{else} \end{cases}

Sum의 eval은 다음과 같아요.

eval_{\text{sum}}(x) = \begin{cases} e + t & \text{if $x = (e, t)$} \\ 0 & \text{else} \end{cases}

두 Algebra 모두 두가지 정보를 이용해서 스스로를 정의해요. 하나는 초기값이고, 다른 하나는 리스트 element의 타입 E와 결과 타입 T를 받는 evaluation 함수 $\times T \rightarrow T$ 죠. 뭔가 익숙하지 않나요?

class Foldable t where
    foldr :: (a -> b -> b) -> b -> t a -> b

프로그래머들이 매일매일 쓰는 fold (aka reduce) 함수가 바로 두가지 정보를 받아서 List E Algebra를 구현해주는 함수였습니다! (정확히 말하면 오른쪽부터 접는 foldr/reduceR) fold 를 쓸때마다 프로그래머는 항상 새로운 Algebra를 정의하고 있었던거죠.

Flux

Redux나 NgRx를 써보신 분들중 아마 List와 비슷하다는 점을 눈치채신 분들도 계실거에요. 특히나 초기 App State를 설정해주는 부분과 새로운 App State를 계산하는 부분을 reducer라고 불리는 부분이 리스트가 reduce를 사용하는것과 많이 일치하죠. 각각 다른 파라메터를 받는 세개의 dispatcher를 가진 Flux를 정의해볼게요:

\begin{gathered} \begin{aligned} & \text{Flux } AppState \\ & initialState : \textbf{1} \rightarrow AppState \\ & dispatch1 : \textbf{1} \times T \rightarrow T \\ & dispatch2 : A \times T \rightarrow T \\ & dispatch3 : B \times C \times T \rightarrow T \\ \end{aligned} \\ \cdot \cdot \cdot \end{gathered}

이 Algebra의 eval 함수는 다음과 같겠죠:

\rightarrow T

타입은 집합이잖아요? distributive 성질을 이용해서 하나로 합치면:

\rightarrow T

List E Algebra 로 바꿀 수 있어요. Flux도 결국 List Algebra 였던거죠.

위 내용은 F-Algebra라는 수학적 이론을 바탕으로 쓰여졌어요. F-Algebra에 대해 공부해보고싶다면 여길 추천:

Category Theory for Programmers: F-Algebra

전반적인 카테고리 이론을 공부하고 싶다면 여길 추천:

Category Theory for Programmers

Math3ma: Category Theory

Monad가 Monoid인 이유 수학 없이 이해하기

Ingun 전인건 — Wed, 25 Mar 2020 04:54:33 +0000

Motivation

저는 처음 모나드/모노이드를 배울때 누군가가 “모나드는 모노이드일 뿐이야” 라고 설명해줬으면 얼마나 좋았을까 생각해요. 그걸 알았다면 두개를 따로 따로 배우느라 시간낭비 하지 않았을텐데 하는 아쉬움이있어요. 생각해보니 대부분의 프로그래머를 위한 Monad 와 Monoid 학습 자료들을 보면 Monad의 경우 업계에서 Monad란 무엇인가?! 라는 주제의 글을 금지하고 있을정도로 깊이있는 탐구보단 프로그래머관점에서의 표면적인 이해를 위한 자료가 많아요. Monoid 도 마찬가지죠. 물론 프로그래머로써 이 둘을 깊게 이해할 필요는 없어요. 그 때문인지 이 둘이 독립적으로 다뤄질 때가 많아요.

이 글에서는 최대한 프로그래머 관점에서 쉽게 모나드를 모노이드로 설명하고, 모노이드로 정의를 내려봄으로써 독자가 이 두 토픽을 확실하게 이해할 수 있게끔 노력해볼거에요.

들어가기 앞서 둘이 같다는걸 이해하는것은 전혀 어렵지 않고 손뻗으면 닿는, 바로 눈앞에있다는것을 먼저 보여드릴게요

우선 모나드와 모노이드의 문서상 정의부터 비교해보죠.

\begin{aligned} &\text{Monad} \\ &\mu :: T^2 \rightarrow T \\ &\eta :: I \rightarrow T \\ &\mu(T,\mu(T^2)) = \mu(\mu(T^2),T) \\ &\mu(\eta(I),T) = \mu(T,\eta(I)) = T \\ \end{aligned} \hspace{1em} \begin{aligned} &\text{Monoid} \\ &\otimes :: T \times T \rightarrow T \\ &i \\ &t_1 \otimes (t_2 \otimes t_3) = (t_1 \otimes t_2) \otimes t_3 \\ &i \otimes t = t \otimes i = t \\ \end{aligned}

각 수식의 정확한 의미는 몰라도 굉장히 비슷한게 보이시나요?

각도를 다르게 해서 봐보죠.

\text{Monad} \\ \text{}\\ \begin{gathered} 1 \\ \darr_{\eta} \\ T \\ \end{gathered} \hspace{1em} \begin{gathered} T^2 \\ \darr_{\mu} \\ T \\ \end{gathered} \hspace{1em} \begin{gathered} T \times 1 \\ \darr \\ T \\ \end{gathered} \begin{gathered} \xrightarrow{id\times\eta} \\ \\ \rightarrow \\ \end{gathered} \begin{gathered} T^2 \\ \darr_{\mu} \\ T \\ \end{gathered} \begin{gathered} \xleftarrow{\eta\times id} \\ \\ \leftarrow \\ \end{gathered} \begin{gathered} 1 \times T \\ \darr \\ T \\ \end{gathered} \hspace{1em} \begin{gathered} T^3 \\ \darr_{id \times \mu} \\ T^2 \\ \end{gathered} \begin{gathered} \xrightarrow{\mu\times id} \\ \\ \xrightarrow{\mu} \\ \end{gathered} \begin{gathered} T^2 \\ \darr_{\mu} \\ T \\ \end{gathered}

\text{Monoid} \\ \text{}\\ \begin{gathered} 1 \\ \darr_{id} \\ T \\ \end{gathered} \hspace{1em} \begin{gathered} T\times T \\ \darr_{\otimes} \\ T \\ \end{gathered} \hspace{1em} \begin{gathered} T \times 1 \\ \darr \\ T \\ \end{gathered} \begin{gathered} \xrightarrow{1\times id} \\ \\ \rightarrow \\ \end{gathered} \begin{gathered} T \times T \\ \darr_{\otimes} \\ T \\ \end{gathered} \begin{gathered} \xleftarrow{id \times 1} \\ \\ \leftarrow \\ \end{gathered} \begin{gathered} 1 \times T \\ \darr \\ T \\ \end{gathered} \hspace{1em} \begin{gathered} T\times T\times T \\ \darr_{1 \times \otimes} \\ T\times T \\ \end{gathered} \begin{gathered} \xrightarrow{\otimes\times 1} \\ \\ \xrightarrow{\otimes} \\ \end{gathered} \begin{gathered} T\times T \\ \darr_{\otimes} \\ T \\ \end{gathered}

모양이 비슷하죠? 자세하게는 몰라도 둘이 같은걸 뜻한다는 느낌을 받을거에요.
모나드의 각 property들이 모노이드에 어떻게 대응하는지만 이해한다면 둘이 같은걸로 보이게 될거에요.

Monad <-> Monoid

프로그래머한테 모나드 T의 정의는 다음과같은 signature를 가진 두 함수의 존재에요.

\mu(T^2) \rightarrow T \newline \eta(I) \rightarrow T

프로그래머한테는 보통 $μ\mu$ 는 join으로, $η\eta$ 는 return으로 많이 알려져 있죠. $T$ 는 모나드 타입이고 $T^2$ 는 모나드 타입 $T$ 를 두번 적용 한 거에요. 모나드 List가 $T$ 라면 List의 List가 $T^2$ 가 되겠죠.

물론 signature가 똑같다고 아무 함수나 되는건 아니에요. 만족해야하는 조건이 있어요. 하지만 이 조건을 컴파일러 레벨에서 강제할 수 있는 언어가 (제가알기론)없다보니 이름하야 monadic law는 프로그래머들에겐 무시당할 때가 많죠. 하지만 모나드가 모노이드라는 사실을 이해하기위해선 Monadic law 도 이해해야해요. 왜냐하면 Monadic Law는 두가지 (join의 룰, return의 룰)이 있는데 이 각각이 모노이드의 Associativity 와 Identity 에 대응이 되기 때문이에요.

모나드의 Join <-> 모노이드의 Associativity

$μ\mu$ (혹은 join) 이 지켜야 하는 룰은 다음과 같아요

\mu(T,\mu(T^2)) = \mu(\mu(T^2),T)

모나드 타입 ( $T^3$ )를 T로 두번 $μ\mu$ 한다고 할때 $μ(T2,T)\mu(T^2, T)$ 를 먼저 하든 $μ(T,T2)\mu(T,T^2)$ 를 먼저 하든 결과는 똑같아야 한다는 뜻이에요. 다시 List로 예를 든다면 List<List<List>>.join().join()의 결과와 List<List<List>>.map(join).join()의 결과는 언제나 같아야 한다는 뜻이에요.

이 룰이 다음과같은 Monoid의 Associativity 에 대응해요.

(t_1 \otimes t_2) \otimes t_3 = t_1 \otimes (t_2 \otimes t_3)

그림으로 표현해보면 더 와닿을거에요

Monad의 $μ\mu$ 가 operator역할로 Monoid로써 Associativity 를 만족시켜줘요.

모나드의 세 T는 줄서서 하나의 타입으로 evaluate되길 기다리고 있어요. 양쪽 어느 쌍이 먼저 evaluate 되든 상관없어요 왜냐하면 monadic law 에 의해 결과는 똑같을것이기 때문이죠. 이 모나드의 property 는 모노이드의 associativity 와 대응돼요. 모노이드의 세 T는 줄서서 다른 algebraic value 로 evaluate 되길 기다리고있죠. 모노이드 역시 양쪽 어느 쌍이 먼저 evaluate 되든 상관없어요. 모노이드기 때문이죠.

모나드의 Return <-> 모노이드의 Identity

$η\eta$ (혹은 return) 가 지켜야 하는 룰은 다음과 같아요

\mu(\eta(I),T) = \mu(T,\eta(I))

$η\eta$ 로 만든 T의 T든, T의 $η\eta$ 로 만든 T든 $μ\mu$ 를 적용했을 때의 결과값은 똑같아야 한다는 뜻이에요. 다시 List로 예를들면 List.map(return).join()의 결과와 return(List).join()의 결과는 같아야 한다는 뜻이에요.

이 룰은 Monoid의 Identity 에 대응해요

\otimes t = t \otimes i = t

이것도 그림으로 보면 더 와닿을거에요.

$η\eta$ 도 Monoid로써 Identity를 만족시켜줘요.

근데 $μ\mu$ 가 대응되는 점과 비교해봤을때 이상한 점이 있죠. $μ\mu$ 도 함수고 $⊗\otimes$ 도 함수니깐 짝궁이 맞다고 쳐도 $η\eta$ 는 함수인데 Identity는 오브젝트잖아요!? 이점에대해서 설명하자면 $η\eta$ 는 정확히는 모노이드의 오브젝트 x에 Identity 오브젝트를 곱해주는 (함수로 정의될 수 있는)행위 와 대응이 되는거에요. 즉 함수와 함수끼리 대응되는거라고 볼 수 있죠.

마무리

결론은 모나드는 파라메터 한개짜리 제네릭 타입의 모노이드에요. 이 글이 모나드/모노이드의 시야를 넓히는데 도움이 됐길 바래요.

이 토픽에 대한 더 자세하게 공부하고 싶다면 Category Theory for Programmer - Monads Categorically 를 추천해요.
전반적인 카테고리 이론에 대해 공부하고 싶다면
Category Theory for Programmers
Math3ma - Category Theory
개인적으로 푼 Category Theory for Programmers각 챕터 Challenges의 솔루션: ingun37.github.io/answers/

Mac, Linux 에서 vscode 하스켈 개발환경 세팅하기 업데이트(2020-10-10)

Ingun 전인건 — Sun, 22 Mar 2020 16:08:31 +0000

이 글은 과거에 Haskell-Ide-Engine (이하 hie) 이라는 language server 를 이용한 개발환경 구축에 대해서 설명했었어요. 이태껏 HIE 를 이용한 방법을 설명했던 이유는 당시 하스켈은 아직 공식 language server가 없었고, 그나마 있던 방법들중 HIE 가 가장 큰 커뮤니티와 완성도를 자랑했기 때문이에요.

하지만 며칠전 하스켈을 쓸 일이 생겨서 확인해보니 공식 language server 가 생긴걸 확인했어요. 바로 Haskell-Language-Server (이하 HLS) 에요.

2020년 1월 HIE 개발자들과 GHCIDE 개발자들이 하스켈 개발환경의 표준을 만들자는 취지로 합심해서 만든게 바로 HLS 에요.

써보니 다음과 같은 관점에서 너무나도 좋아졌다는걸 확인했어요.

전체적인 개발환경 설치에 걸리는 시간과 용량이 엄청나게 단축됐어요. 기존에 genesis 상태만 10GB 넘게 차지하면서 반나절씩 걸리던게 이젠 정말 200mb(정확하지 않음) 남짓 차지하면서 순식간에 되는것 같아요.
전반적인 개발환경 세팅이 매우 단순해졌어요. 기존에는 nix랑 cachix도 알아야 하고, ghc버전관리도 직접 해야 하는 등 매우 복잡했던 설치 과정이 rustup을 표방한 ghcup이 알아서 다 해주더라고요. 애초에 제가 이 글을 써야만 했던 이유가 사라진거죠.

따라서 이 글에선 기존 내용을 지우고, 그냥 링크만 걸어놓아도 될것같다는 생각을 했습니다.

여기서 ghcup을 설치하시고,
https://gitlab.haskell.org/haskell/ghcup-hs/-/blob/master/README.md

여기 README 를 읽으면서 language server 랑 vscode client 를 설치하시면 됩니다.

https://github.com/haskell/haskell-language-server#ghcup

UIView 는 File’s Owner 가 될 수 없어요

Ingun 전인건 — Sun, 22 Mar 2020 15:22:08 +0000

재사용 가능한 .xib를 만들때 UIView 를 File’s owner 로 설정하는 방법이 널리 퍼져있어요. 사실 이게 잘못된 방법인데 잘 작동하니깐 사람들이 모르고 쓰는것 같아서 이걸 바로잡고자 이 글을 써봤어요.

애플 개발자 문서 를 보시면 File’s owner를 다음과같이 설명하고 있어요

Typically, you use outlets in the File’s Owner object to store references to the top-level objects of a nib file.

top-level object 가 뭐냐고요? 같은 문서 밑에 보시면 top-level object에 대해 다음과같이 또 써있어요:

The top-level objects are the subset of these objects that do not have a parent object. The top-level objects typically include only the windows, menu bars, and custom controller objects that you add to the nib file.

설명대로라면 UIView 가 File’s owner 로써 알맞는 후보가 아니라는걸 알 수 있어요. UIView 는 부모 오브젝트가 없다는 점은 만족하죠(.xib 파일에는 UIView 가 최상위 오브젝트니까요) 하지만 windows 도 아니고 menu bars 도 아니고 controller object 도 아니에요.

문서상으로는 그렇다고 쳐도 잘 작동 하니깐 장땡 아니냐고요?

진짜 잘 작동 하는걸까요?

절대 아니에요. UIView 를 File’s owner 로 설정하면 어떤 문제점들이 생기는지 설명드릴게요

UIView 를 File’s owner 로 쓴다는 아이디어 자체가 구조적으로 모순이에요. .xib 파일은 원래 다양한 UIView 타입의 오브젝트들을 가지고 있을 수 있게끔 만들어졌어요. 근데 생각해보면 .xib 파일은 단 하나의 File’s owner 만을 가질 수 있잖아요? 그렇다면 .xib 파일은 하나의 UIView 타입이면서 동시에 다수의 UIView 타입일 수 있다는 말이되잖아요? 모순이죠.

이 모순은 악마를 하나 낳아요. 바로 contentView 에요. 첫째로 contentView는 프로그래머가 모든 뷰를 자기 아래로 정렬시키는 노가다를 하게 만들어요. 결과적으로 뷰의 어떠한 컴포넌트를 접근하든 contentView.-를 써서 자기 자신을 거치게 만들어요. 이놈만 없었다면 편하고 자연스러운self 를 쓸 수 있었을텐데 말이죠. 그뿐만이 아니에요. 이 악마때문에 UI 구조랑 일치하는 자료구조를 정의할 수가 없어요. Declarative UI 로발전하고있는 이 시점에 시대를 역행하게 만들죠.

재사용 가능한 `.xib`를 만드는 옳은 방법

샘플 프로젝트를 만들어 볼게요

이게 기존의 잘못된 구조에요:

우리는 다음과같은 새로운, 옳은 구조를 쓸거에요:

차이점으로는

File’s owner는 공석으로 냅둘거에요
MyView 는 File’s owner 가 아닌 object class 로써 outlet 들을 제공할거에요
contentView 는 사라지리거에요
여전히 storyboard 에서 쓸 수 있을거고, 코드에서 인스턴스화 할 수 있을거에요
한 .xib파일에 여러개의 view 오브젝트들을 정의할 수 있을거에요.

샘플프로젝트는 깃헙에 올려놓았어요:

ingun37 / xib4StoryboardSample

MyView 라는 클래스를 하나 정의해보아요

class MyView: UIView {
    @IBOutlet weak var subView1:UIView!
    @IBOutlet weak var subView2:UIView!

    //This is helper function so you can instantiate MyView like
    //let view = MyView.loadViewFromNib()
    static func loadViewFromNib() -> MyView {
        let bundle = Bundle(for: self)
        let nib = UINib(nibName: "MyViews", bundle: bundle) //“MyViews” is name of xib file
        return nib.instantiate(withOwner: nil, options: nil).first {
            ($0 as? UIView)?.restorationIdentifier == "1"
        }! as! MyView //You will set restorationIdentifier later
    }
}

outlet 들이랑 .xib파일 도 하나 만들고, 자식 뷰도 몇개 만들고 MyView 로 세팅 해봅시다

Outlet 을 연결하고

Restoration id 도 설정하세요. 이건 xib 에 있는 뷰들을 구별하기위한 id 에요. 뷰 오브젝트가 하나만 존재한다면 굳이 안써도 돼요.

이제 코드에서 다음과같이 인스턴스화 할 수 있어요.

let view = MyView.loadViewFromNib()

이제 스토리보드에서 쓰는 방법을 알아볼건데 그전에 먼저 말하고싶은게 있어요. contentView 를 쓸거에요. 아까 contentView 를 악마라고 까놓고선 이제와서 또 쓰는건 무슨 위선 이냐고 생각할 수 있는데 그렇지 않아요. 이번에 쓰는 contentView 는 기존의것과 많이 다른거에요. 이번거는 기존의 hack 이나 ad-hoc 같은 용도의 contentVew 가 아니에요. 바로 modularization of storyboard adaptation 라는 사명을 가진 뷰랍니다. 말 그대로 스토리보드 어댑터의 역할을 하는 모듈이죠. 그리고 이번거는 프로그래머의 앞길을 가로막지 않을거에요. 다음과같은 특징이 있기 때문이죠

이번 contentView 는 오로지 코드상으로만 존재해요. UI 빌더 상의 정의를 필요로 하지 않죠. 다른말로 .xib 파일이나 .storyboard파일을 건들지 않아요.
더 나아가서 이번 contentView 는 MyView 클래스에서 완전히 모듈화 돼서 떨어져 나가요. 위에서 말한 스토리보드 어댑터 역할을 하는 클래스로 따로 정의돼요. 이해가 안간다면 이따가 보여드릴 샘플을 보면 이해가 가실거에요
다른 클래스로 모듈화가 되었으니, 기존 contentView 처럼 자료구조를 방해할 일이 없겠죠? 이제 뷰의 property 에 접근할때마다contentView.- 를 쓸 일이 없을거에요

이제 스토리보드에서 쓰는 방법을 알아봅시다

어댑터 클래스를 정의해요

class StoryMyView1:UIView {
    var contentView:MyView
    required init?(coder aDecoder: NSCoder) {
        contentView = MyView.loadViewFromNib()
        super.init(coder: aDecoder)
        contentView.frame = bounds
        addSubview(contentView)
    }
}

끝났어요 이제 .storyboard UI 빌더에서 다음과 같이 쓰면 돼요.

다음과같이 한 xib 파일에 여러개의 view 를 정의할 수 있다는 점도 잊지말고요

UIView shouldn’t be File’s Owner

Ingun 전인건 — Sun, 22 Mar 2020 14:20:26 +0000

I want to correct the widely spread practice of setting UIView as File’s Owner for Xib files.

Checkout Apple Doc and see what File’s Owner is for.

Typically, you use outlets in the File’s Owner object to store references to the top-level objects of a nib file.

What’s top-level object? Same document defines top-level object as:

The top-level objects are the subset of these objects that do not have a parent object. The top-level objects typically include only the windows, menu bars, and custom controller objects that you add to the nib file.

Does UIView qualify for the job? No! UIView may have no parents (because UIView is the top object in xib) but it’s neither windows, menu bars nor controller object.

Some may argue that it may be technically unqualified but it performs perfectly!

Does it?

No it doesn’t. It works poorly. Here’s why

The mere idea is structural paradox. An .xib file is supposed to have multiple objects and each object can be a different type of UIView class. But there can be only one File’s owner for an .xib file. So it means a .xib is one kind of UIView and at the same time, a multiple kinds of UIView? That can’t be right can it?

This paradox leads to the undesirable consequence: the contentView aka the wrapper view. Firstly, it gives you some extra works of making every UI components to be under the contentView. Secondly, It forces you to use contentView instead of self. Thirdly, and mostly, it prevents data structure from conveying it’s UI structure. Data structure is always better when it is conveying it’s UI structure and that's what declarative UI is all about. Take SwiftUI. Apple is moving to SwiftUI where such contentView kind of ad-hoc would never exist.

Right way to make reusable `Xib` For `UIView`

Let me walk you through a sample project.

This is the conventional structure:

In this sample we will employ this new structure:

File’s owner will be left vacant.
The outlets will be served through MyView class instead of File’s Owner.
contentView will be gone.
It will keep all the utilities of being able to be called in storyboard and instantiated anywhere in code.
It will enable you to have multiple views in single .xib file.

Sample project is available here:

ingun37 / xib4StoryboardSample

Define custom UIView class with some outlets.

class MyView: UIView {
    @IBOutlet weak var subView1:UIView!
    @IBOutlet weak var subView2:UIView!

    //This is helper function so you can instantiate MyView like
    //let view = MyView.loadViewFromNib()
    static func loadViewFromNib() -> MyView {
        let bundle = Bundle(for: self)
        let nib = UINib(nibName: "MyViews", bundle: bundle) //“MyViews” is name of xib file
        return nib.instantiate(withOwner: nil, options: nil).first {
            ($0 as? UIView)?.restorationIdentifier == "1"
        }! as! MyView //You will set restorationIdentifier later
    }
}

Create an Xib With an view object. Make some subviews that will be connected to outlets. Set the object’s class to MyView.

Connect the outlets

Set restoration ID. This is for identification among view objects in same .xib. You wouldn’t need it if there were only one view object in the Xib.

Now you are all set to instantiate from anywhere in code.

let view = MyView.loadViewFromNib()

I’ll get to how to call it from storyboard in a moment but before that, let me tell you first that I’ll be using a kind of wrapper view and let me explain this seemingly hypocritical discrepancy between my previous contempt for the idea of using contentView and the following usage of kind of wrapper view.

This time it’s very different. This kind of wrapper view is not just a hack or ad-hoc like it was in the conventional way. This time, it exists only for modularization of storyboard adaptation and it will never bother you throughout the development once set because:

This time the contentView only exists in code. It will not require to have a body in any UI builder file. In other words it will not affect our .xib or .storyboard file.
In fact, it doesn’t even exist in MyView class. We will define another class for, once again, modularization of storyboard adaptation at minimum code. Don’t understand? It will come clear once you see the following sample.
Since it’s seperated into another class, it won’t affect data structure either. You don’t have to write contentView.- everytime to access it’s subcomponent in the code.

With that in mind, here’s how to use it with storyboard.

Define a wrapper class

class StoryMyView1:UIView {
    var contentView:MyView
    required init?(coder aDecoder: NSCoder) {
        contentView = MyView.loadViewFromNib()
        super.init(coder: aDecoder)
        contentView.frame = bounds
        addSubview(contentView)
    }
}

That’s it! You can use it in .storyboard just like any other views

Don’t forget you can now have multiple views in single .xib. (Use restorationID for identification)

Forem: Ingun 전인건

Flux와 List의 Algebra 구조는 같다

글을 읽기 위한 배경 지식

프로그래머에게 Algebra는 무엇인가?

리스트 Algebra

Flux

Monad가 Monoid인 이유 수학 없이 이해하기

Motivation

Monad <-> Monoid

모나드의 Join <-> 모노이드의 Associativity

모나드의 Return <-> 모노이드의 Identity

마무리

Mac, Linux 에서 vscode 하스켈 개발환경 세팅하기 업데이트(2020-10-10)

UIView 는 File’s Owner 가 될 수 없어요

재사용 가능한 .xib를 만드는 옳은 방법

ingun37 / xib4StoryboardSample

UIView shouldn’t be File’s Owner

Right way to make reusable Xib For UIView

ingun37 / xib4StoryboardSample

재사용 가능한 `.xib`를 만드는 옳은 방법

Right way to make reusable `Xib` For `UIView`