[번역] The color of Composable functions

https://newsletter.jorgecastillo.dev/p/the-color-of-composable-functions 의 번역 버전입니다.

The color of Composable functions 🖍️

Composable 함수들은 표준 함수와 다른 제한 사항과 기능들을 가지고 있습니다. Composable 함수들을 다른 형식으로 매우 구체적인 관심사를 모델링 합니다. 이러한 차이들은 "함수의 색상(특성 정도로 생각하면 됩니다)"의 형태로 이해할 수 있습니다 여러분야의 함수 형태 중에 한 부분을 차지하고 있습니다.

 

Function coloring (함수의 색)

"Function coloring" 컨셉은 2015 년 구글 다트 팀의 블록포스트에 작성된 "What color is your funtion?" 에서 Bob nystrom 에 의해 처음으로 설명한 개념입니다. (구글에서 프로그래밍 언어 만드시는 분이네요..!) 그는 비동기, 동기 함수가 어떻게 서로 어울리지 않는지 설명했어요. 동기 함수에서는 비동기 함수를 호출할 수 없고, 동기함수를 비동기 함수로 만들거나 비동기 함수를 호출하고 결과를 기다릴 수 있는 대기 메커니즘을 제공하지 않는 한 비동기 함수를 호출할 수 없다고 설명했어요. 그래서 호환성을 위해 일부 라이브러리나 언어에서는 Promise 나 async/await 도입했어요.  그리고 Bob 은 동기 비동기 함수를 서로 다른 함수 색을 가졌다 라고 카테고리화 했어요.

 

코틀린 언어에서는 suspend 가 위와 같은 문제를 해결하기 위해 제시되었어요. 하지만 다른 suspend 함수에서만 suspend 함수를 호출할 수 있기 때문에 suspend 함수에도 특별한 색을 가지고 있다고 볼 수 있어요. 표준 함수와 suspend 함수를 혼합된 프로그램을 구성하려면 코루틴이 실행 지점(코루틴 빌더 함수들)이 필요 합니다. 이러한 통합은 개발자가 보기에는 투명하다고 보기 어렵습니다.

 

전반적으로 다음과 같은 제한이 예상 됩니다. 매우 다른 성격을 가진 개념을 두 함수를 모델링 하고 있기 때문에, 마치 두개의 다른 언어를 사용하는 것과 같다고 볼 수 있습니다. 즉시 결과를 계산할 것이라 생각하는 연산(sync)과 시간에 지나면 unfold 되어 최종적으로 결과를 만드는 연산(async) 이 있고, async 는 완료하는데 시간이 오래 걸릴 수도 있습니다.

 

Coloring in Compose (컴포즈의 색)

제트팩 컴포즈의 경우 Composable 함수의 경우도 위와 동일 합니다. 표준 함수에서 Composable 어노테이션이 있는 함수를 투명하게 호출할 수 없습니다. 만약 표준함수에서 Composable 함수를 호출하고 싶다면 Composition.setContent 와 같은 통합을 위한 지점이 필요합니다. Composable 함수는 표준 함수 와는 완전히 다른 목표를 가지고 있습니다. Composable 함수는 프로그램 로직을 위해 고안된 것이 아니라, 노트 트리의 변경 사항을 설명하기 위해 설계 되었습니다.

 

하지만 Composable 함수의 장점 중 하나는 일반적인 함수 로직을 이용해서도 UI 를 선언할 수 있다는 점입니다. 즉 표준 함수에서 Composable 함수를 호출해야 하는 경우가 존재합니다. 예를 들어 아래와 같은 함수가 있습니다.

@Composable
fun SpeakerList(speakers: List<Speaker>) {
  Column {
    speakers.forEach { // Standard function
      Speaker(it) // Composable function
    }
  } 
}

 

Speaker Composable 함수는 forEach 람다에서 호출하는데 원래라면 표준 함수에서 Composable 함수를 호출하니 컴파일러는 문제가 있다고 이를 해석해야 하지만 실제로는 문제가 없는 것으로 보입니다. 어떻게 이런일이 가능한 것 일까요 !?

 

Inline (인라인)

그 이유는 인라인 때문이였습니다~! 컬렉션 연산자들은 inline 으로 작성되어 있습니다. 그래서 람다를 호출하는 쪽에 인라인 처리해서 마치 추가적인 간섭이 없는 것 처럼 컴파일러가 해석하게 도와줍니다. 위의 예제에서 Speaker Composable 호출은 SpeakerList 의 본문 안에서 인라인 처리되어 있는데, 둘다 Composable 함수이기 때문에 허용 됩니다. 인라인 기능을 활용하면, Composable 에 일반적인 로직을 작성할 때 발생할 수 있는 함수 색상 문제를 우회할 수 있습니다. 결과적으로 트리는 Composable 함수들로만 구성됩니다.

 

But, is coloring really a problem ? (함수 색상이 정말로 문제가 될까요 ?)

두개의 타입을 결합해서 매번 한 기능에서 다른 기능으로 이동해야 한다면 문제가 될 수도 있습니다. 그러나 suspend 함수나 @Composable 함수는 그런식으로 사용되지 않습니다. 두 함수 모두 코루틴 런치 블록이나 setContent 같은 통합 지점이 필요하기 때문에 해당 지점을 넘어가면 완벽하게 같은 색상이 지정된 콜스택을 얻을 수 있습니다.

그리고 같은 색상으로 "colored" 되는 것은 사실은 이점이 됩니다. 왜냐하면 컴파일러와 런타임에서 표준 함수로는 불가능한 언어 스펙에서 지원하는 고급 기능들을 사용할 수 있기 때문 입니다.

 

Language features (언어 기능들)

코틀린 에서는 suspend 를 사용하면 비동기면서 논 블록킹 프로그램을 매우 관용적이며 표현력 있는 방식으로 작성할 수 있습니다. 함수 앞에 단순히 suspend modifier 를 추가하는 것만으로 매우 복잡한 개념을 표현할 수 있는 능력을 얻게됩니다. 마찬가지로 @Composable 어노테이션이 붙음으로써 표준 함수에는 없는 기능인 재시작 가능(restartable), 건너뛰기 가능(skippable), 반응형 함수를 만들 수 있습니다. 

 

그럼 20000-