# 스크린과 블록 라이프사이클 이벤트 모바일 앱과 리액티브 웹 앱에만 적용 OutSystems의 모바일 및 리액티브 웹 앱에서는 스크린과 블록이 일련의 단계로 구성된 라이프사이클을 따릅니다. 이러한 단계에는 앱을 열어 기본 스크린에 들어갈 때, 다른 스크린으로 이동할 때, 또는 스크린이나 블록의 데이터를 변경할 때 등이 있습니다. 스크린 또는 블록의 데이터는 다음과 같습니다: - 입력 파라미터 - 변수 - 집계와 데이터 액션 - 검증 메시지 모바일 또는 리액티브 웹 앱을 구현할 때, 개발자는 이벤트 핸들러 액션 세트를 사용하여 이러한 단계에 대응할 수 있습니다. 이러한 이벤트 핸들러는 개발자에게 스크린과 블록 라이프사이클의 가시성과 특정 이벤트가 발생했을 때 로직을 구현할 기회를 제공합니다. 이벤트 핸들러는 스크린과 블록의 속성 편집기의 이벤트 섹션 또는 데이터 조회가 완료되었을 때 트리거되는 이벤트 핸들러의 경우, 집계나 데이터 액션의 속성 편집기에서 확인 및 정의할 수 있습니다. ## 라이프사이클 단계 ### 애플리케이션을 열 때 ![OutSystems에서 애플리케이션을 열 때의 라이프사이클 단계를 보여주는 그림. 스플래시 스크린 표시, 사용자 역할 확인, 데이터 조회 이벤트 등이 포함되어 있습니다.](https://success.outsystems.com/TK_Resource/c59e64dc-5cd6-457e-85e9-363939a19277 "애플리케이션 시작 시 라이프사이클") 애플리케이션을 여는 것은 스크린이 로드되는 상황 중 하나입니다(다른 상황은 다른 스크린에서 이동할 때입니다). 이 경우, 앱은 설정된 스플래시 스크린을 표시한 후 기본 스크린으로 이동합니다. 이 글에서는 DOM 또는 Document Object Model에 대해 자주 언급합니다. DOM에 대해 더 알아보려면 MDN의 [DOM 소개](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction)를 참조하세요. 스플래시 스크린을 표시하는 동안, 애플리케이션은 사용자 역할과 스크린에 접근할 수 있는 권한이 있는 역할(스크린 속성에서 정의)을 대조합니다. 이 확인 후, Initialize 이벤트가 발생하고, 그에 해당하는 이벤트 핸들러 액션인 [On Initialize](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-initialize)가 트리거됩니다. 이 이벤트가 발생하는 시점에서는 기본 스크린의 DOM이 완전히 로드되지 않았기 때문에, DOM이 필요 없는 로직(기본 데이터 초기화 등)을 구현하기 위해 이 이벤트 핸들러를 사용할 수 있습니다. On Initialize 이벤트 핸들러가 종료되면, 기본 스크린의 집계와 데이터 액션이 동시에 데이터 조회를 시작하고(위 이미지의 GetContacts와 GetProfileImages 예시), 스크린의 DOM이 로드되며, [Ready](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-ready) 및 [Render](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-render) 이벤트 핸들러가 실행됩니다. 이 두 이벤트의 차이점은 Ready 이벤트는 스크린을 열 때만 발생하는 반면, Render 이벤트는 스크린의 데이터(입력 파라미터, 변수, 집계와 데이터 액션, 또는 검증 메시지 등)가 변경될 때마다 발생한다는 것입니다. 두 이벤트 핸들러 모두 로드된 DOM에 대해 작동시킬 수 있습니다. 이 시점에서는 데이터가 아직 조회되지 않았을 수 있으므로, 스크린의 데이터에 접근하는 것은 피하세요. 집계와 데이터 액션으로부터 데이터가 조회되기 전이라도, 스크린은 정적 리소스로 사용자에게 표시됩니다. 이 상황을 방지하려면 오프라인 퍼스트 구현 접근법을 채택하세요. 스크린의 집계와 데이터 액션이 데이터 조회를 완료하면, 이러한 데이터 소스에 바인딩된 위젯은 자동으로 조회된 데이터로 업데이트됩니다. 각 집계와 데이터 액션의 [After Fetch](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-after-fetch) 이벤트 핸들러가 실행되고, 그 후 Render 이벤트(스크린의 데이터가 변경되었기 때문)가 이어집니다. 각 After Fetch 이벤트에 대해, 애플리케이션은 Render 이벤트를 실행합니다. ### 스크린 간 이동 시 ![OutSystems에서 스크린 간 이동 시 라이프사이클 단계를 보여주는 플로우차트. 새 스크린의 DOM 로드와 이전 스크린의 삭제가 강조되어 있습니다.](https://success.outsystems.com/TK_Resource/8c225d3a-7279-44d1-9c9d-b913ebb736fe "스크린 간 이동의 라이프사이클") 한 스크린에서 다른 스크린으로의 이동은 애플리케이션에서 흔히 볼 수 있는 패턴입니다. 이는 보통 버튼이나 리스트 아이템 클릭 등 사용자의 조작에 의해 트리거됩니다. OutSystems에서 스크린 간 이동은 새 스크린이 로드된 후 이전 스크린이 삭제됨을 의미합니다. 이동이 시작되면, 대상 스크린의 DOM이 즉시 로드되기 시작합니다. 이는 삭제될 스크린의 DOM과 대상 스크린의 DOM이 동시에 존재함을 의미합니다. 이전 스크린의 DOM은 대상 스크린의 Render 이벤트 이후에만 삭제되어, 스크린 간 빠르고 부드러운 전환을 보장하고 대상 스크린의 로딩 단계가 사용자에게 보이는 것을 방지합니다. 가장 먼저 실행되는 이벤트 핸들러는 [On Initialize](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-initialize)입니다. 애플리케이션은 대상 스크린의 DOM 로딩을 계속하고, 애플리케이션이 열릴 때 섹션에 설명된 대로 이벤트가 이어집니다. 이러한 이벤트는 대상 스크린에 속하기 때문에, 활성 스크린은 대상 스크린이며, DOM의 `active-screen` 클래스는 해당 스크린의 요소에 할당됩니다. 대상 스크린의 [Render](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-render) 이벤트 이후, 스크린 간 전환이 발생하고 이전 스크린은 최종적으로 DOM에서 삭제됩니다. 이는 대상 스크린의 Render 이벤트와 이전 스크린의 Destroy 이벤트 사이에 두 스크린의 DOM이 모두 이용 가능함을 의미합니다. ### 스크린 또는 블록 데이터 변경 시 스크린 또는 블록의 데이터 요소 값을 변경할 때마다, 애플리케이션은 자동으로 반응합니다. 따라서 Render 이벤트가 트리거되고, 데이터에 의존하는 UI 요소가 자동으로 업데이트됩니다. 전통적인 웹 앱처럼 UI 요소를 명시적으로 업데이트할 필요가 없습니다. 스크린 또는 블록의 집계와 데이터 액션의 경우, 그들의 새 값은 UI 요소에 자동으로 업데이트되지만, 쿼리를 명시적으로 재실행해야 합니다. 이는 로직 내의 [Refresh Data](https://success.outsystems.com/ja-jp/documentation/11/reference/outsystems_language/logic/implementing_logic/logic_tools/refresh_data/) 플로우 요소를 사용하여 수행할 수 있습니다. 데이터가 조회된 후, [After Fetch](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-after-fetch) 이벤트가 발생하고, 집계 또는 데이터 액션에서 반환된 데이터가 스크린 또는 블록 데이터에 속하고 변경되었기 때문에 Render 이벤트도 발생합니다. 예를 들어, 특정 연락처의 상세 정보와 그 연락처에 대한 통화 목록을 표시하는 스크린을 상상해보세요. 통화를 조회하기 위해, 현재 연락처 식별자가 할당된 스크린 변수 값으로 필터링된 집계를 사용합니다. 연락처가 변경되면, 스크린은 새 연락처의 상세 정보를 표시하기 위해 스크린 변수는 새 연락처 식별자를 포함하도록 변경됩니다. 이 새 연락처에 대한 통화 목록을 조회하려면, 집계를 다시 실행해야 합니다. 이를 수행하려면, 로직 내의 Refresh Data 플로우 요소를 호출하고, 해당하는 집계 또는 데이터 액션을 선택하기만 하면 됩니다. 쿼리가 새 통화 목록을 반환하면, 스크린 내의 리스트는 자동으로 업데이트됩니다. ### 블록 파라미터 변경 시 ![OutSystems에서 블록 파라미터를 변경할 때의 라이프사이클 이벤트를 보여주는 시퀀스 다이어그램. Parameters Changed 이벤트와 Render 이벤트가 포함되어 있습니다.](https://success.outsystems.com/TK_Resource/fa0bf311-5faf-4afe-887a-bd0371deec99 "블록 파라미터 변경의 라이프사이클") 입력 파라미터 중 하나가 변경될 때 블록에 알림과 업데이트를 가능하게 하기 위해, 애플리케이션은 블록의 [Parameters Changed](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-parameters-changed) 이벤트 핸들러를 실행합니다. 이 이벤트 핸들러의 일반적인 사용 예는 입력 파라미터에 의존하는 집계 또는 데이터 액션을 재실행하는 것입니다. 위 이미지에서는 캘린더 날짜가 변경된 후, 차트의 새 값을 조회하기 위해 쿼리가 다시 실행되고 있습니다. 입력 파라미터는 블록 데이터의 일부이기 때문에, Parameters Changed 이벤트 이후에 [Render](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-render) 이벤트도 트리거됩니다. ## 라이프사이클 이벤트 핸들러 |이벤트|설명| |---|---| |[On Initialize](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-initialize)|사용자의 스크린 접근 권한을 확인한 후, 스크린으로의 이동과 데이터 조회 전에 발생합니다. 블록에서는, 이동 후에 발생합니다. 기본 데이터를 설정하여 스크린 또는 블록을 초기화하는 데 사용할 수 있습니다.| |[On Ready](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-ready)|스크린 또는 블록의 DOM이 준비된 후, 전환이 시작되기 전에 발생합니다.| |[On Render](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-render)|스크린 또는 블록의 On Ready 이벤트 핸들러 직후, 그리고 스크린 또는 블록의 데이터가 변경될 때마다 발생합니다. 서드파티 컴포넌트를 업데이트하는 데 사용할 수 있습니다.| |[On After Fetch](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-after-fetch)|집계 또는 데이터 액션이 데이터 조회를 완료한 후, 이 데이터가 스크린 또는 블록에 렌더링되기 전에 발생합니다. 조회된 데이터에 대해 작업하는 데 사용할 수 있습니다.| |[On Parameters Changed](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-parameters-changed)|부모 스크린 또는 블록이 입력 파라미터 중 하나를 변경할 때마다 블록에서 발생합니다. 블록 내에서 입력 값의 변경은 이 이벤트 핸들러를 트리거하지 않습니다. 변수 업데이트 등의 블록 파라미터 변경에 반응하는 데 사용할 수 있습니다.| |[On Destroy](https://success.outsystems.com/ja-jp/documentation/11/building_apps/application_logic/screen_and_block_lifecycle_events/#on-destroy)|스크린 또는 블록을 파괴하고 DOM에서 제거하기 전에 발생합니다. 이벤트 리스너 제거 등, 컴포넌트가 파괴될 때 로직을 구현하는 데 사용할 수 있습니다.| ### On Initialize On Initialize 이벤트 핸들러는 사용자의 스크린 접근 권한을 확인한 후, 스크린으로의 이동과 데이터 조회를 시작하기 전에 실행됩니다. 블록에서는, 이 플로우에 서버 액션 호출이나 로컬 스토리지 조작을 포함하면, 이 액션이 완료되기 전에 블록의 렌더링이 시작될 수 있습니다. 이 플로우에서 렌더링에 영향을 주는 변수를 설정하면 문제가 발생할 수 있습니다. 주의사항: - 이 이벤트 핸들러 액션은 단순하게 유지하고, 로컬 스토리지 조작 등의 느린 액션은 피하세요. 스크린이나 블록의 렌더링이 지연될 수 있습니다. - 이 액션은 데이터가 조회되기 전에 실행되므로, 스크린이나 블록의 데이터에 접근하는 것은 피하세요. 이 이벤트 핸들러에서 구현할 수 있는 사용 사례: - 입력에 기반하여 변수 할당하기. - 랜덤 숫자 등의 JavaScript 계산에 기반하여 변수 할당하기. - 사용자가 스크린을 볼 권한이 없는 경우, 애플리케이션을 다른 스크린으로 리디렉션하기(이벤트 핸들러가 스크린에 속한 경우에만 가능). - 스크린의 입력에 기반하여 자식 블록의 파라미터 할당하기. - JavaScript의 window 객체의 변수에 접근하기. ### On Ready On Ready 이벤트 핸들러는 스크린 또는 블록이 준비되었을 때, 즉 DOM이 준비된 후, 첫 렌더링 후에 실행됩니다. 블록에서는, 이 이벤트는 부모 스크린 또는 블록의 같은 이벤트 전에 발생합니다. 스크린 또는 블록의 빠르고 부드러운 렌더링을 보장하기 위해, 이 이벤트는 스크린으로의 전환이 끝나기 전에 트리거됩니다. 주의사항: - 이 이벤트가 트리거되면, 이전 스크린과 현재 스크린의 DOM이 로드되어 있습니다. 생성되고 있는 스크린에서 작업을 확실히 수행하려면, `active-screen` 클래스를 가진 HTML `div` 요소에 대해서만 로직을 실행하세요. - 이 이벤트 핸들러 액션은 단순하게 유지하고, 병행하여 실행되는 스크린 집계나 데이터 액션을 사용하여, 이용할 수 없을 가능성이 있는 데이터를 조작하는 것은 피하세요. - 이 액션은 데이터가 조회되기 전에 실행되므로, 스크린이나 블록의 데이터에 접근하는 것은 피하세요. 이러한 데이터에 대한 로직을 개발해야 하는 경우, 각각의 집계 또는 데이터 액션의 On After Fetch 이벤트 핸들러를 사용하세요. 이 이벤트 핸들러에서 구현할 수 있는 사용 사례: - DOM이 필요한 서드파티 컴포넌트 초기화하기. - DOM 요소에 리스너 추가하기. - 입력 위젯에 포커스 설정하기. - JavaScript의 window 객체에 리스너 추가하기. ### On Render On Render 이벤트 핸들러는 스크린 또는 블록이 렌더링될 때마다 실행됩니다. 즉, 스크린 또는 블록이 열릴 때마다(On Ready 이벤트 핸들러의 실행 직후), 그리고 스크린의 데이터가 변경된 후에 실행됩니다. 블록에서는, 이 이벤트는 부모 스크린 또는 블록의 같은 이벤트 전에 발생합니다. 이 이벤트 핸들러를 사용하여 프로그레스 바 등의 서드파티 컴포넌트를 업데이트할 수 있습니다. 주의사항: - 스크린 또는 블록의 데이터를 변경하면, 이 데이터가 변경될 때마다 On Render 이벤트가 다시 트리거되어, 앱이 무한 루프에 빠질 수 있으므로, 데이터 변경은 피하세요. - 이 이벤트 핸들러 액션은 단순하게 유지하고, 서버 요청 등의 느린 액션은 피하세요. 스크린 또는 블록의 렌더링이 지연될 수 있습니다. - 스크린 또는 블록의 첫 렌더링 시에는 데이터가 이미 조회되었다는 보장이 없으므로, 스크린 또는 블록의 데이터에 접근하는 것은 피하세요. 이러한 데이터에 대한 로직을 개발해야 하는 경우, 각각의 집계 또는 데이터 액션의 On After Fetch 이벤트 핸들러를 사용하세요. 이 이벤트 핸들러에서 구현할 수 있는 사용 사례: - 서드파티 컴포넌트를 업데이트하기 위해, 스크린 또는 블록의 데이터 변경에 기반하여 작동하기. - On Ready 이벤트 핸들러와 같은 사용 사례. ### On After Fetch On After Fetch 이벤트 핸들러는 집계 또는 데이터 액션이 데이터 조회를 완료한 직후에 실행됩니다. 각 집계 또는 데이터 액션에는 자체 On After Fetch 이벤트 핸들러가 있으므로, 해당 데이터 소스에서 조회한 데이터에 기반하여 작동하는 로직을 구현할 수 있습니다. 주의사항: - On After Fetch 이벤트 핸들러가 실행될 때, 데이터는 도착하여 이용 가능하지만, 위젯에 바인딩되지 않았습니다. 즉, 위젯은 아직 업데이트되지 않았습니다. 이 이벤트 핸들러에서 구현할 수 있는 사용 사례: - 쿼리에 의해 반환된 첫 번째 또는 마지막 레코드를 변수에 할당하기. - 마스터 상세 패턴에서는, 리스트의 리스트를 입력하기 위해 쿼리를 반복하기. - 다른 쿼리에 의존하는 쿼리의 경우, 이 이벤트 핸들러를 사용하여 의존하는 집계를 트리거할 수 있습니다. ### On Parameters Changed On Parameters Changed는 부모 스크린 또는 블록이 블록의 입력을, 외부 블럭은 자신의 입력을 변경한 후에 실행되는 블록 전용 이벤트 핸들러입니다. 다른 블록 내에 블록이 있고, 외부 블록의 입력 변경이 중첩된 블록의 입력에 영향을 미치는 경우, 외부 블록의 On Parameters Changed 이벤트 핸들러는 중첩된 블록의 같은 이벤트 전에 실행됩니다. 이 이벤트 핸들러를 사용하여 변수 업데이트나 집계와 데이터 액션의 재실행 등, 입력 파라미터의 변경에 블록을 적응시킬 수 있습니다. 이 이벤트 핸들러에서 구현할 수 있는 사용 사례: - 그 입력 파라미터에 의존하는 집계 또는 데이터 액션 업데이트하기. - 입력 파라미터에 의존하는 변수 재계산하기. ### On Destroy On Destroy 이벤트 핸들러는 스크린 또는 블록이 파괴될 때 실행됩니다. 스크린에서는, 이 이벤트는 새 스크린으로의 전환이 끝났을 때 발생합니다. 블록에서는, 이 이벤트는 블록이 DOM에서 제거되기 전에 발생합니다. 이 이벤트는 톱다운 순서로 발생합니다: 중첩된 블록이 있는 스크린이 있는 경우, 이벤트는 먼저 스크린에서 발생하고, 다음에 외부 블록에서 발생하며, 그 후 중첩된 블록에서 발생합니다. 이 이벤트 핸들러를 사용하여 이벤트 리스너 제거 등, 스크린 또는 블록의 흔적을 지우는 로직을 구현할 수 있습니다. 주의사항: - 이 이벤트가 트리거되면, 현재 스크린과 대상 스크린의 DOM이 로드되어 있습니다. 파괴되고 있는 스크린에서 작업을 확실히 수행하려면, `active-screen` 클래스를 가진 HTML `div` 요소에 대해서만 로직을 실행하세요. - 이 이벤트 핸들러 액션은 단순하게 유지하고, 서버 요청 등의 느린 액션은 피하세요. 스크린 또는 블록의 삭제가 지연될 수 있으며, 스크린을 종료하는 경우 다음 스크린의 로딩도 지연될 수 있습니다. 이 이벤트 핸들러에서 구현할 수 있는 사용 사례: - 서드파티 컴포넌트의 destroy 액션 호출하기. - 플러그인을 다시 실행하기 위해 DOM 정리하기. - JavaScript 리스너 제거하기.