SwiftUI 핵심 기능

오늘은 SwiftUI의 작동 원리에 있어 핵심이 되는 개념들을 소개해 드리겠습니다.

이 개념들은 더 나은 코드를 작성하는 데 도움이 될 뿐만 아니라, 오늘 진행될 나머지 발표들의 토대를 마련해 줄 것입니다.

먼저 SwiftUI 뷰에서 자주 사용되는 용어를 자세히 살펴보겠습니다.

그 다음에는 SwiftUI에 내장된 뷰들과 새로운 사용자

정의 뷰를 만드는 데 필요한 논리에 대해 다룰 것입니다.

마지막으로, 의존성과 의도적으로 코드를 구조화하는 방법에 대해 다룰 것입니다.

각 섹션에서 해당 주제에 가장 중요한 개념과, 이 개념들이 코드 작성이라는 큰 그림과 어떻게 연관되는지 설명해 드리겠습니다. 훌륭한 SwiftUI 코드를 작성하는 데 도움이 되길 바랍니다. 자, SwiftUI에서 ‘뷰(view)’라는 용어는 여러 가지 의미를 지닌 용어입니다.

문맥에 따라 세 가지 다른 의미를 가질 수 있어 다소 혼란스러울 수 있습니다.

많은 프레임워크에서 ‘뷰’는 사용자 인터페이스와 화면상의 픽셀을 의미합니다.

SwiftUI에서 ‘뷰’는 프로토콜이기도 합니다. 이는 화면에 표시하고자 하는 내용을 기술한 것입니다.

각 뷰는 구조체(struct)이기 때문입니다. 뷰의 각 인스턴스는 특정 값을 가집니다.

이 세 가지 개념은 모두 서로 관련되어 있습니다. 화면의 픽셀은 뷰에 대한 설명과 해당 특정 뷰 구조체의 실제 값이 결합된 결과물입니다.

뷰에 대한 설명과 이를 구동하는 값들이 결합되어 화면에 최종 픽셀이 표시됩니다.

‘뷰’의 이 세 가지 의미는 앱의 서로 다른 영역에서 나타납니다.

설명은 코드 그 자체입니다.

값은 메모리 내의 인스턴스입니다. 따라서 SwiftUI는 픽셀을 렌더링할 수 있으며, 화면상의 픽셀은 가장 최신이고 정확한 정보를 표시해야 합니다.

이번 발표를 통해 ‘뷰’가 지닌 이러한 다양한 의미들을 하나씩 자세히 살펴보겠습니다.

이러한 맥락을 이해하는 것은 중요하며, 여러분이 직접 작성한 SwiftUI 코드의 문제를 해결하는 데 도움이 될 것입니다. 먼저 ‘뷰’를 ‘설명’의 관점에서 살펴보겠습니다.

SwiftUI에서 뷰는 의도된 방식으로 구성되는 설명입니다.

예를 들어, 영어로 ‘스노클링을 하는 멋진 수중 장면’의 이미지를 원한다고 가정해

봅시다. 이를 설명하려면 ‘수중에서 스노클링을 하는 이미지’라는 문구를 작성하면 됩니다.

SwiftUI에서는 뷰 프로토콜을 사용하여 이 설명을 구성합니다. ‘Image’는 SwiftUI 뷰이며, ‘deep sea’는 영어로

작성한 문구와 마찬가지로 이미지의 이름입니다. 뷰는 SwiftUI에서 제가 원하는 것을 설명합니다.

SwiftUI는 이 뷰를 받아 화면에 무엇을 렌더링할지 결정합니다. 이렇게요. 멋진 사진이네요.

모든 SwiftUI 뷰는 코드로 작성된 설명입니다.

이는 내장 뷰이든 직접 작성한 사용자 정의 뷰이든 상관없이 마찬가지입니다.

Image는 SwiftUI의 내장 뷰 예시입니다.

뷰는 모든 앱의 구성 요소이며, 내장 뷰는 시작하기에 아주 좋은 방법입니다. SwiftUI에는 많은 내장 뷰가 있으며, 각각의 이름은 그 뷰가 만들어내는 결과를 설명합니다.

예를 들어, ‘image’가 이미지를 시각화하는 것과 비슷합니다.

‘Color’는 보라색과 같은 특정 색상으로 프레임 전체를 채우는 뷰입니다.

내장 뷰는 SwiftUI가 이를 하드웨어와 통합하기 때문에 강력합니다.

여기서 이 보라색은 실제로 컨텍스트에 따라 달라지는 보라색입니다.

실제 색상 값은 기기의 컨텍스트에 따라 조정됩니다. 예를 들어, 휴대폰이 밝은 모드인지 어두운 모드인지, 또는 화면에 햇빛이 강하게 비추고 있는지 여부와 같은 요소에 따라 달라집니다. ‘Text’는 ‘Kona Deep Dive’와 같은 문자열을 시각화합니다.

‘Color’와 마찬가지로, ‘Text’ 뷰도 존재하는 컨텍스트에 최적화되어 있습니다.

SwiftUI는 현재 플랫폼에 적합한 글꼴을 사용하여 문자열을 렌더링합니다. iMac과 같은 대형 디스플레이에서는 텍스트 뷰가 Apple Watch와 같은 소형 디스플레이보다 물리적으로 더 커집니다. 텍스트 뷰는 접근성 기능인 ‘Dynamic Type’도 지원합니다.

Dynamic Type을 통해 사용자는 기기에서 표시되는 텍스트의 크기를 조절하여 편안하게 읽을 수 있습니다.

여기서 오른쪽의 휴대폰은 시스템 글꼴 크기가 더 큽니다.

제 SwiftUI 코드의 텍스트 뷰는 내용이 여전히 가독성을 유지할 수 있도록 자동으로 크기가 조정되며, 이를 위해 별도의 코드를 작성할 필요가 없습니다. 각 뷰, 이미지, 색상, 텍스트의 이름은 제가 원하는 내용을 설명하는 단어와 ‘Deep Sea Purple’

및 ‘Kona Deep Dive’와 같은 값이 결합된 형태입니다. 이들은 화면상의 픽셀로 구현됩니다.

내장 뷰는 그 자체로도 유용할 뿐만 아니라 사용자 정의가 가능하기 때문에 훌륭한 출발점이 됩니다.

뷰를 사용자 정의하면 SwiftUI 내장 뷰의 장점을 활용하면서도 앱만의 독특한 개성을 표현할 수 있습니다.

SwiftUI에서 뷰를 사용자 정의하는 방법에는 여러 가지가 있습니다.

앞서 보여드린 제 TextView는 괜찮아 보이지만, 좀 더 인상 깊게 만들 수 있습니다. 뷰 수정자(ViewModifiers)는 개별 뷰를 사용자 정의하는 도구입니다. 이제 코드를 자세히 살펴보겠습니다.

텍스트 뷰를 사용자 정의하는 방법은 다양합니다. 예를 들어, 글꼴의 크기나 색상을 변경하는 것이죠. 이는 위시리스트 앱에서 자주 사용했던 기법입니다. 지금은 간단한 것부터 시작해 보겠습니다. 밝은 색상 배경에서 텍스트 뷰가 시각적으로 돋보이게 하고 싶습니다.

background 수정자는 뷰의 배경을 설정합니다. 배경으로 어떤 뷰든 지정할 수 있습니다. 저는 주황색을 선택했습니다.

배경은 뷰 수정자의 한 예시입니다.

뷰 수정자는 텍스트와 같은 특정 뷰에 호출되는 메서드로, 원본을 포함하는 새로운 뷰를 반환합니다.

원본 텍스트 뷰는 뷰 수정자의 변경 사항으로 감싸져 새로운 뷰를 생성합니다.

저는 뷰 수정자를 뷰를 둘러싸는 래퍼라고 생각하곤 합니다.

이 두 줄의 코드를 합치면, 원래 문자열인 ‘Kona Deep Dive’가 주황색 배경과 함께 표시됩니다.

이는 원래 텍스트 뷰를 약간 수정한 버전입니다. 여러 뷰 수정자를 적용하여 복합적인 사용자 정의 효과를 만들 수 있습니다.

패딩(Padding)도 또 다른 뷰 수정자입니다. 패딩은 적용된 뷰의 가장자리에 특정 값을 추가합니다. 이 경우, 패딩은 TextView의 네 변 모두에 여백을 추가하고, 그 뒤를 이어 주황색 배경이 그 공간을 채우는데, 마치 배경 패딩이 그 앞의 모든 요소를 감싸듯이 말입니다. 따라서 이 세 줄의 코드는 뷰 계층 구조에서 하나의 큰 뷰를 나타냅니다. 뷰 수정자에 대한 마지막 주의사항은 순서가 중요하다는 점입니다. 각 뷰 수정자는 그 위에 있는 코드 줄에만 영향을 미칩니다.

순서를 바꿔서 배경이 먼저 오도록 하면, 주황색은 원래의 TextView에만 적용됩니다.

회색 점선 상자로 표시된 패딩은 나머지 부분에 적용됩니다.

뷰 모디파이어의 순서를 신중하게 결정하세요. 코드가 예상한 대로 작동하지 않는다면, 뷰가 논리적인 순서로 묶여 있는지 확인해 보세요.

뷰 모디파이어는 개별 뷰를 사용자 정의하는 반면, 컴포지션은 여러 뷰를 결합하는 기법입니다.

기존 뷰를 조합하여 나만의 커스텀 뷰를 만들 수 있습니다.

예를 들어, ‘Kona Deep Dive’ 위시리스트의 검색 탭에 이런 행 중 하나를 만들고 싶다고 가정해 봅시다.

이전에 만든 내장 뷰 중 일부를 사용할 수 있습니다.

먼저, ‘search row’ 뷰를 정의하겠습니다.

이것은 구조체(struct)이며 뷰 프로토콜을 준수합니다.

그런 다음 뷰의 본문을 추가하겠습니다. 이는 모든 뷰에 필수적인 요소입니다.

그리고 심해 이미지를 보여주는 이미지 뷰를 추가하겠습니다. 또한 ‘Kona Deep Dive’라고 표시된 텍스트 뷰도 추가하겠습니다. 기본적으로 SwiftUI는 이들을 수직으로 쌓습니다.

저는 이 요소들을 나란히 배치하고 싶으므로, 이미지와 텍스트처럼 수평 스택(H 스택)을 추가하겠습니다. H 스택은 뷰의 일종이지만,

이미지처럼 렌더링할 대상을 지정하는 대신 렌더링 방식을 정의합니다.

SwiftUI의 H 스택은 이미지와 텍스트 같은 모든 하위 뷰를 수평으로 정렬합니다.

오늘 후반부에는 캣이 레이아웃과 SwiftUI에 대한 도구와 기법을 더 깊이 있게 다룰 예정입니다. 더 정교한 뷰를 만들더라도 한 가지 강조하고 싶은 점이 있습니다. 핵심 개념은 동일합니다.

제 검색 행은 제가 원하는 바를 설명한 것이며, SwiftUI는 그 설명을 바탕으로 화면에 픽셀을 렌더링합니다.

구성(Composition)을 활용하면

코드를 더 쉽게 읽을 수 있으며, 검색 행을 한 번 구축해 두면 단 한 줄의 코드만으로 앱의 다른 부분에서도 이를 사용할 수 있습니다. 제 검색 뷰에서는 스택 3개, 이미지 3개, 텍스트 뷰 3개가 필요하지 않습니다. 단 3개의 복합 검색 행 뷰만 사용했습니다.

나중에 검색 행의 배경을 보라색으로 바꾸는 등 어떤 부분을 변경하고 싶다면, 해당 뷰 내에서만 변경하면 됩니다.

이렇게 하면 작성해야 할 코드의 양이 줄어들고, 코드를 읽거나 이해하기도 더 쉬워집니다.

뷰는 구조체(struct)이기 때문입니다. 뷰는 가볍기 때문에, 이처럼 뷰를 더 작은 뷰들로 분할해도 성능에 지장이 없습니다.

내장 뷰와 마찬가지로, 사용자 정의 뷰는 SwiftUI가 화면에 무엇을 그려야 하는지에 대한 우리의 설명을 담고 있습니다. 'Search View'와 같은 이름도 중요하지만, body 내부에 있는 뷰들과 그 나열 순서는 훨씬 더 중요합니다. SwiftUI는 코드 내의 설명을 바탕으로 화면에 픽셀을 그립니다.

이제 한 단계 더 나아가 보겠습니다. 제 검색 행은 의도한 디자인에 꽤 가까워졌지만, 아직 완벽하지는 않습니다.

현재 ‘Kona Deep Dive’ 인스턴스가 세 개 있는데, 여러분은 어떨지 모르겠지만 저는 매년 휴가 계획을 바꾸는 것을 좋아합니다. 앱은 동적이며 변화하는 데이터를 나타냅니다.

버킷 리스트에 있는 다른 여행지들을 표시할 수 있도록 이 내용을 변경할 방법이 필요합니다.

이제 마지막 주제인 ‘의존성’에 대해 이야기해 보겠습니다.

SwiftUI 뷰는 데이터에 의해 구동됩니다. 그 데이터가 심해 이미지나 ‘Kona Deep Dive’라는 문자열처럼 동일하게 유지되든, 아니면 데이터가 변경되든 상관없습니다. 오늘 보여드린 모든 뷰는 데이터에 의존합니다.

화면의 픽셀은 부분적으로는 ‘이미지’와 같은 설명의 결과이고, 부분적으로는 ‘심해’와 같은 데이터의 결과입니다.

앞서 모든 뷰는 구조체(struct)라고 언급했는데, 이는 모든 뷰가 값형(value type)이며, 뷰의 모든 인스턴스에는 값이 있다는 것을 의미합니다.

저는 뷰 인스턴스를 다음과 같이 시각화하는 것을 좋아합니다. 위쪽에는 ‘이미지’와 같은 뷰 이름이, 아래쪽에는 ‘심해’와 같은 데이터가 있는 형태죠.

SwiftUI는 화면의 픽셀을 렌더링하기 위해 데이터를 포함한 특정 뷰 인스턴스를 사용합니다.

픽셀이 렌더링되면 SwiftUI는 해당 인스턴스를 폐기합니다. 더 이상 필요하지 않기 때문입니다.

이것이 뷰의 세 번째 의미입니다. 값으로서의 뷰.

뷰의 인스턴스들. 이 특정 값들이 화면의 픽셀을 구동합니다.

각 뷰 인스턴스는 일시적으로 존재합니다. 수명이 짧습니다. 필요할 때 생성됩니다. SwiftUI의 메모리 내에 존재합니다. 그리고 픽셀이 렌더링되면 뷰의 역할은 끝나고 인스턴스는 폐기됩니다.

인스턴스를 폐기하는 것이 나쁜 일이거나 큰 위험이 따르는 일은 아니라는 점에 유의하세요. 뷰는 가볍고 생성하기 쉽습니다.

저는 뷰를 템플릿으로 생각하곤 합니다. 같은 것을 반복해서 찍어내듯 화면의 픽셀을 생성하는 것이죠. 대부분의 경우, 이러한 템플릿은 유연하고 동적인 데이터를 나타냅니다.

예를 들어, 제 앱에서는 심해에 집중하고 있지만, 교토의 이미지도 하나 더 필요합니다.

이것도 뷰의 인스턴스이지만, 이 인스턴스는 값이 약간 다릅니다. '교토'라는 이미지 이름은 '심해'와 다릅니다.

SwiftUI는 이미지 이름 때문에 값이 다른 이러한 이미지 뷰를 받아, 서로 다른 이미지를 생성합니다.

이제 이러한 유연성을 활용하여 검색 행의 코드를 다시 살펴보겠습니다.

이제 이미지 이름과 텍스트를 하드코딩하는 대신, 제 검색 행은 이미지 이름과 여행 제목에 대한 인수를 받습니다.

이 버전의 검색 행은 더 유연합니다. 여전히 ‘코나 심해 다이빙’ 행을 만드는 데 사용할 수 있을 뿐만 아니라, 다른 여행에도 활용할 수 있습니다.

이를 통해 실제 디자인에 한 걸음 더 가까워졌습니다. 검색 뷰에서 새로운 검색 행을 사용할 때,

'Mammoth Blush'나 'Kyoto Mystique'와 같은 다양한 이미지와 여행 이름을 모두 제공합니다. 그리고 이 방식이 훨씬 더 낫습니다. 데이터가 화면의 픽셀을 제어하고 있으며, 여전히 컴포지션에서 얻은 깔끔한 코드를 활용할 수 있습니다.

이 검색 뷰 구현은 여전히 위시리스트에 있는 최종 버전을 단순화한 것임을 명심해 주세요. 실제 검색 기능은 데이터를 동적으로 조회한 다음, 검색 필드에 입력된 이미지와 문자열을 기반으로 검색 행을 채웁니다.

이 검색 행에 대해 한 가지 더 강조하고 싶은 점이 있습니다.

앞서 본 이미지 뷰와 마찬가지로, 각 검색 행 인스턴스는 여행 이름과 사진 이름에 따라 서로 다른 값을 가집니다.

SwiftUI는 이를 쉽게 비교하여 서로 같지 않다는 것을 파악할 수 있습니다. SwiftUI는 화면에 픽셀을 그린 후 뷰 인스턴스를 해제합니다.

픽셀이 렌더링되었으므로 더 이상 인스턴스가 필요하지 않기 때문입니다.

이제 SwiftUI가 의존성을 어떻게 처리하는지에 대해 조금 더 이야기해 보겠습니다.

제 검색 행의 경우를 예로 들어보겠습니다. 설명은 제 뷰 코드입니다.

뷰의 값이 다르면 화면에 표시되는 픽셀도 달라집니다.

SwiftUI는 의존성을 통해 중요한 값들을 추적하는데, 여기서 중요한 값이란 데이터에 따라 픽셀이 올바르게 보이거나 잘못 보이게 만들 수 있는 종류의 값을 의미합니다.

작동 방식은 다음과 같습니다. SwiftUI가 body를 처음 실행할 때, 읽은 모든 값을 그래프로 추적합니다.

이 그래프의 첫 번째 부분은 검색 행을 나타내는 노드입니다.

`body`에서 SwiftUI는 이미지 뷰의 ‘사진 이름’ 값을 읽으므로,

‘사진 이름’ 노드와 ‘검색 행’을 가리키는 아래쪽 화살표를 추가합니다.

SwiftUI는 ‘여행 이름’ 값도 읽으므로, ‘여행 이름’ 노드와 화살표도 추가합니다. SwiftUI가 이 두 가지를 추적하는 이유는, 픽셀이 올바르게 표시되려면 올바른 사진 이름과 올바른 여행 이름을 나타내야 하기 때문입니다.

이 중 하나라도 변경되면, 예를 들어, 새로운 사진 이름을 입력하면. 이 빨간 점으로 표시한 것처럼, 검색 행의 픽셀은 최신 상태가 아니게 되므로 SwiftUI는 새로운 픽셀을 그려야 합니다.

의존성은 뷰의 입력값과 같습니다.

의존성 추적은 SwiftUI가 업데이트를 매우 효율적으로 수행하는 이유 중 하나입니다.

뷰와 데이터가 많은 앱에서. 무언가 하나만 변경될 때마다 SwiftUI가 모든 것을 다시 그려야 한다면 매우 비효율적일 것입니다.

앱에서는 데이터가 빈번하게 변경되므로, 이 경우 불필요한 업데이트가 많이 발생하게 됩니다.

대신 SwiftUI는 의존성을 추적합니다.

여기서는 화살표로 표시했는데, 이는 어떤 뷰가 특정 데이터에 의존하는지를 나타냅니다.

이 시스템을 통해 무언가 하나가 변경되면, SwiftUI는 하류에 있는 요소들만 재계산하고 다시 그립니다.

앱 내에서 상황이 빠르고 빈번하게 변경되더라도, 의존성 추적 덕분에 SwiftUI는 효율성을 유지합니다. 이 시스템은 정교하며, 더 좋은 소식이 있습니다. 이 그래프를 직접 구축할 필요가 없습니다.

SwiftUI가 의존성 그래프를 통해 자동으로 구축해 줍니다.

SwiftUI는 각 뷰가 `body`를 실행할 때마다 읽는 속성을 추적합니다.

이 시스템은 그래프를 지속적으로 최신 상태로 유지합니다.

이 그래프를 직접 구축하거나 관리할 필요는 없지만, 코드를 작성할 때 유의해야 할 몇 가지 사항이 있습니다.

뷰를 구축할 때는 뷰를 가볍게 유지하고, `body` 내에서 필요한 정보가 무엇인지, 그리고 해당 뷰의 변경 사항이 전체 뷰를 무효화해야 하는지 여부를 고려하세요.

의존성을 최소화하여 뷰를 가볍게 유지하는 것이 가장 좋으며, 그래야 SwiftUI가 중요한 경우에만 뷰를 다시 그릴 수 있습니다. 그렇다고 해서 복잡한 뷰를 만들 수 없다는 뜻은 아닙니다.

이는 앞서 제가 검색 뷰의 행에서 했던 것처럼, 복잡한 뷰를 더 작고 단순한 조각들로 분할해야 한다는 의미입니다.

데이터를 표현하고, 화면의 픽셀을 변경해야 할 때에만 변경 사항을 전달할 수 있도록 적절한 도구를 사용하세요. 뷰가 데이터에 의존하는 방식에는 몇 가지가 있습니다. 한 가지 방법은 앞서 제가 했던 것처럼 이미지나 여행의 구체적인 이름을 지정하여 데이터를 뷰에 직접 전달하는 것입니다.

데이터를 생성하는 또 다른 방법은 `at state`를 사용하는 것입니다.

제 동료인 콜이 발표에서 `at state`와 데이터 흐름을 위한 다른 옵션들에 대해 더 자세히 다룰 예정이지만, 저는 여기서 몇 가지 기본 사항을 다루고자 합니다.

'at' 상태로 감싸진 속성입니다. SwiftUI에 뷰의 전체 수명 동안 해당 정보를 저장하도록 지시합니다.

이는 뷰가 뷰 계층 구조에 존재하는 전체 기간을 의미합니다. 간단한 예시를 통해 시연해 보겠습니다.

위시리스트의 검색 탭에서입니다. 검색 창에 입력을 시작하면 결과가 필터링됩니다.

문자 ‘J’를 입력하면, 가장 최근에 추가된 항목들이 ‘hike’, ‘Joshua Tree’, ‘Cliff jump’와 같이 검색 문자열을 포함하는 제 여행 및 활동 기록으로 대체됩니다.

또 다른 문자, ‘O’를 입력하면 결과가 계속해서 필터링됩니다.

제가 앱에 추가한 모든 여행 및 활동 기록 중에서 ‘Joshua Tree’만이 ‘j o’라는 문자열을 포함하고 있습니다. 이것이 바로 앱의 상태입니다. 검색 필드에 입력한 문자열이 결과와 화면의 픽셀을 제어합니다.

'상태(state)'가 어떻게 작동하는지 보여주기 위해 간소화된 예제를 만들어 보겠습니다. 이것은 'Simple Search'라고 부르는 검색 뷰의 간소화된 버전입니다. 실제 검색 뷰의 핵심 기능은 갖추고 있지만, 디자인은 일부 간소화되었습니다.

본문에는 두 개의 뷰만 있습니다. 텍스트 필드와 TextView를 사용하고 있습니다.

TextView는 단순히 ‘결과가 여기에 표시됩니다’라고 표시되는 자리 표시자입니다. 이것은 제가 프로토타이핑을 할 때 자주 사용하는 방법입니다. 자리 표시자를 넣어두는 것이죠. 나중에 검색 결과를 보여주는 사용자 정의 뷰로 대체할 예정입니다.

텍스트 필드는 SwiftUI에 내장된 또 다른 뷰입니다. 입력을 수집하기 위한 용도입니다. 사용자가 탭하면 키보드가 열리고, 입력한 문자열이 표시됩니다.

여기서 시작 프롬프트를 제공하고, 입력된 문자열을 Search Value라는 변수에 저장하도록 SwiftUI에 지시합니다.

달러 기호는 바인딩을 나타내는 구문으로, 콜이 나중에 자세히 설명할 또 다른 데이터 흐름 도구입니다.

SearchValue 속성에 At 상태 속성 래퍼를 적용했습니다.

이는 SwiftUI가 업데이트가 이루어지는 동안 ‘search value’의 값을 유지하도록 지시합니다.

초기값은 빈 문자열입니다.

텍스트 필드를 탭하면 커서가 깜빡이며 입력이 가능함을 나타냅니다. ‘J’를 입력하면 ‘search value’의 값이 빈 문자열에서 ‘J’로 변경됩니다. SwiftUI는 해당 값을 유지하며, 이에 따라 간단한 검색을 위한 픽셀을 업데이트할 수 있습니다.

‘O’를 추가하여 ‘Joshua Tree’로 필터링을 좁혀갈 때도 같은 현상이 발생합니다.

SwiftUI는 ‘search string j o’의 값을 유지하므로 업데이트가 이루어지는 동안에도 검색 진행 상황을 지속적으로 반영할 수 있습니다. ‘At state’는 뷰의 전체 수명 동안 유지되어야 하는 정보를 모델링하는 가장 간단한 방법입니다.

검색 탭에 머무는 동안 내 ‘search value’는 지속되므로 계속해서 내용을 추가할 수 있습니다.

탭을 벗어나서 나중에 다시 돌아오면, 값은 빈 문자열로 다시 초기화됩니다.

이는 위시리스트(Wishlist)에서 실제 검색 뷰를 구축하는 첫 단계에 불과합니다. 다음 단계에서는 검색 값 문자열과 일치하는 여행 및 활동 정보로 자리 표시자 텍스트 뷰를 대체해야 합니다.

지금은 상태의 이러한 측면에 집중해 보세요.

'at state'는 SwiftUI의 속성 래퍼입니다.

SwiftUI에서 속성에 `at state`가 지정되면, SwiftUI는 해당 속성이 앱의 ‘진실의 원천’임을 인식하고, 업데이트가 이루어지는 동안에도 그 값을 유지합니다.

상태는 뷰의 전체 수명 동안 메모리에 남아 있습니다.

이는 앱이 텍스트 필드에 입력된 문자열처럼 동적이고 복합적인 데이터를 표시할 수 있음을 의미합니다.

SwiftUI에서 종속성을 구성하는 방법은 여러 가지가 있으며, 콜이 나중에 각각에 대해 자세히 설명할 것입니다. 지금은 한 가지만 강조하고 싶습니다. 이 도구들이 어떻게 작동하는지 배우는 데 시간을 투자하세요. 그렇게 해야만 SwiftUI와 호환되도록 의존성을 올바르게 모델링할 수 있습니다.

오늘 다룬 바와 같이, 뷰는 SwiftUI의 기본 구성 요소입니다. 뷰가 사용되는 다양한 맥락을 더 깊이 이해하면, 프레임워크 자체를 이해할 뿐만 아니라 코드의 품질도 향상시킬 수 있습니다.

오늘 남은 발표 내용에 대해 말씀드리겠습니다. 위시 리스트의 다양한 영역을 탐색하실 때, 이러한 솔루션의 이론적 배경에 집중해 보시기 바랍니다.

이렇게 하면 배운 내용을 여러분의 앱에 직접 적용할 수 있습니다.

제 발표에서 다룬 내용 중 다음 사항들을 명심해 주세요.

SwiftUI에 내장된 뷰를 활용하여 나만의 커스텀 뷰를 만들어 보세요. 앱만의 독특한 특징을 표현하기 위해 다양한 수정자를 탐구해 보세요.

뷰를 새로 만들거나 기존 뷰를 재검토할 때는 뷰를 가볍게 유지하는 것을 잊지 마세요. 각 뷰가 실제로 어떤 데이터에 의존해야 하는지 고려하고, 복잡한 뷰를 더 단순하고 작은 단위로 분해하세요. 이러한 기본 원칙을 염두에 두면, 앞으로 발생할 수 있는 문제들을 더 잘 해결할 수 있을 것입니다. 참석해 주셔서 대단히 감사합니다.