최근 개발 환경이 바뀌면서 구현이 그 어느 때보다 쉬워졌습니다. Mendix 위젯을 통해 진동 코딩매력이 넘칩니다. 그냥 편히 앉아 AI에게 코드 생성을 요청하세요. 몇 번의 시행착오 끝에 제대로 작동하는 위젯과 괜찮은 UI를 얻을 수 있을 겁니다. 정말 멋지지 않나요?

하지만 이러한 겉보기에 단순한 모습은 기만적일 수 있습니다. AI가 초기 스캐폴딩을 가속화할 수 있다는 것은 의심의 여지가 없지만, 중요한 진실은 여전히 ​​남아 있습니다. 바로 시스템에 대한 이해가 필요하다는 것입니다. 이러한 기본적인 이해가 없다면 AI가 생성한 코드에만 의존하는 것은 근본적인 원리를 제대로 이해하지 못한 채 Stack Overflow에서 해결책을 맹목적으로 복사하는 것과 마찬가지입니다.

위젯 개발 Mendix 애플리케이션 개발은 고유한 과제를 안고 있으며, 개발 프로세스와 애플리케이션의 장기적인 성공에 영향을 미치는 신중한 결정이 필요합니다. 적절한 아키텍처 선택부터 데이터 처리 및 성능 최적화에 이르기까지, 각 결정에는 나름의 장단점이 있습니다.

사용 가능한 다양한 접근 방식을 살펴보고 그 의미를 이해하면 더욱 정보에 기반한 선택을 내리고 강력하면서도 확장 가능한 위젯을 만들 수 있습니다. Mendix 위젯 개발.

위젯 아키텍처 - 올바른 선택하기

위젯을 빌드할 때 Mendix최적의 접근 방식을 결정하기 위해 아키텍처 결정부터 시작하세요. 선택 사항은 위젯의 복잡성에 따라 크게 달라지며, 다음 사항을 고려해야 합니다.

• 위젯과 조합 Mendix 구성 요소들
• 컨테이너 위젯
• 여러 위젯
• 로더 위젯 접근 방식

가장 먼저 떠오르는 접근 방식은 전체 컴포넌트에 대해 하나의 위젯을 만드는 것입니다. 기본 컴포넌트에서는 간단하지만, 컴포넌트가 복잡하고 여러 개의 상호작용 동작을 포함하는 경우 더욱 어려워집니다.

이것을 사용하여 탐색해 보겠습니다. 할 일 목록 위젯을 예로 들어 보겠습니다. 동일한 위젯을 구현하는 세 가지 다른 접근 방식에 대해 설명하겠습니다.

접근 방식 1: 목록 컨테이너로 단일 위젯 사용

이 방식에서는 데이터 소스를 할 일 목록 위젯 설정의 일부로 포함합니다. 위젯이 전체 목록의 렌더링을 처리하여 뷰를 완벽하게 제어할 수 있습니다. 예를 들어, 항목을 세로, 가로 또는 표준 레이아웃에서는 불가능한 사용자 지정 레이아웃을 사용하여 카드 형태로 렌더링할 수 있습니다. Mendix 목록 구성 요소.

하지만 위젯 내에서 페이지 매김, 정렬, 필터링, 지연 로딩 동작 등 목록 관련 문제를 모두 처리해야 합니다. 즉, 기존 기능을 활용하는 대신 이러한 기능을 처음부터 구현해야 합니다. Mendix의 내장 최적화 기능입니다.

데이터 처리 복잡성

다음으로 중요한 과제는 작업 및 데이터 업데이트를 처리하는 것입니다. 데이터 소스가 읽기 전용이므로 Todo 항목을 직접 수정할 수 없습니다. 대신, 마이크로플로를 통해 변경 사항을 전달하려면 더미 속성이 필요합니다. 이로 인해 다음과 같은 여러 구현 과제가 발생합니다.

업데이트 작업

항목 삭제나 할 일 상태 전환과 같은 간단한 작업의 경우 별도의 동작을 구현할 수 있습니다. 그러나 더 복잡한 업데이트의 경우 모든 변경 사항을 단일 마이크로플로에 전달하거나 각 업데이트 동작(상태 전환, 제목 변경, 마감일 변경, 우선순위 변경 등)에 대해 별도의 마이크로플로를 생성해야 합니다.

성능 고려 사항

대용량 데이터 세트를 다룰 때는 자체적인 페이지네이션 로직을 구현해야 합니다. 여기에는 페이지 크기 관리, 무한 스크롤 시 스크롤 이벤트 처리, 그리고 사용자가 수천 개의 항목을 탐색할 때 원활한 성능 보장 등이 포함됩니다.

메모리 관리

위젯 내에서 전체 데이터 세트를 처리하므로, 특히 모바일 기기나 큰 목록을 다룰 때는 메모리 사용량에 유의해야 합니다. 페이지네이션을 사용하면 이 문제를 완화할 수 있습니다.

동작 변수

10.21.0 버전부터 액션 변수를 사용할 수 있게 되어 이전보다 구현이 더 쉬워졌습니다. 이전 버전에서는 액션 뒤에 있는 MF가 매개변수를 가질 수 없었고, MF가 더미 객체의 값을 직접 가져와야 했습니다.

구성 복잡성

이러한 추가 설정으로 인해 위젯 설정이 더욱 어려워집니다. Mendix 개발자는 여러 주요 구성에 대한 확실한 이해가 필요합니다. 개발자는 데이터 전달을 위한 더미 객체를 구성하고, 다양한 동작에 적합한 마이크로플로를 생성하고, 실패한 작업을 처리하기 위한 적절한 오류 처리를 보장하는 방법을 배워야 합니다. 또한, 여러 사용자가 동일한 항목을 편집할 때 데이터 일관성을 유지하려면 세심한 주의와 계획이 필요합니다.

장점

완벽한 렌더링 제어
위젯은 목록 렌더링(카드, 수직, 수평 레이아웃, 사용자 정의 애니메이션, 드래그 앤 드롭 인터페이스)을 완벽하게 제어할 수 있습니다.

고급 필터링 및 정렬
위젯은 표준을 넘어서는 복잡한 정렬 알고리즘, 다중 열 정렬 및 고급 필터링 옵션을 구현할 수 있습니다. Mendix 기능.

일관된 스타일링
모든 것이 하나의 위젯에 포함되어 있으므로 구성 요소 전체에서 스타일의 일관성을 유지하기가 더 쉽습니다.

맞춤 상호작용
대량 작업, 단축키, 복잡한 선택 패턴 등 고급 사용자 상호 작용을 구현할 수 있습니다.

단점

모놀리식 복잡성
위젯 코드 내에서 복잡성이 증가한 모놀리식 구조를 만들어서 유지 관리와 디버깅이 더 어려워집니다.

성능 구현 부담
페이지 나누기, 정렬, 필터링, 지연 로딩 동작을 효율적으로 구현하려면 상당한 노력이 필요합니다.

스타일링 통합 과제
위젯 스타일을 앱의 전반적인 디자인 시스템 및 테마 변경과 일치시키는 것이 더 어렵습니다.

복잡한 설정 요구 사항
복잡한 설정 Mendix 개발자는 더미 객체, 여러 개의 마이크로플로, 위젯의 내부 데이터 흐름에 대한 이해가 필요합니다.

복잡성 테스트
모든 것이 하나의 구성 요소 내에 밀접하게 결합되어 있기 때문에 개별 기능을 테스트하기가 더 어렵습니다.

접근 방식 2: 목록 항목 위젯

또 다른 옵션은 레버리지입니다 Mendix의 내장 목록 구성 요소(예: 갤러리 (Gallery) 위젯, 목록보기및 데이터 그리드. 이 경우에는 항목 위젯만 빌드하고 제공된 목록 컨테이너 내에서 사용합니다. Mendix.
이 접근 방식은 근본적으로 서로 다른 구성 요소 간의 문제를 분리합니다. Mendix 목록 위젯은 페이지 매김, 지연 로딩, 정렬, 필터링 등 복잡한 목록 관리 작업을 모두 처리합니다. 이러한 컨트롤과 패턴은 Mendix 개발자의 경우 설정이 훨씬 쉬워지고 기존 패턴을 따릅니다.

활용 Mendix의 내장 최적화

사용하여 Mendix의 기본 목록 구성 요소를 사용하면 다음과 같은 이점을 자동으로 얻을 수 있습니다.

• 최적화된 데이터 검색: Mendix 다음을 포함하여 효율적인 데이터 검색 패턴을 자동으로 구현합니다. 검색 및 집계 전체 데이터 세트가 아닌 개수만 필요할 때 데이터베이스 쿼리를 줄이는 최적화입니다.
• 내장된 페이지 매김: 구성 가능한 페이지 크기를 통한 기본 페이지 매김 처리로 서버 부하를 줄이고 클라이언트 측 성능을 개선합니다.
• 레이지 로딩: 사용자가 스크롤할 때 데이터를 자동으로 레이지 로딩하여 불필요한 데이터 검색을 방지하고 초기 페이지 로드 시간을 개선합니다.
• 캐싱 메커니즘: Mendix 중복된 서버 요청을 줄이는 지능형 캐싱 전략을 구현합니다.

간소화된 데이터 관리

새 항목을 추가하는 경우, 위젯 외부에서 팝업 페이지, 모달 또는 별도의 양식으로의 탐색 기능을 통해 처리할 수 있습니다. 이러한 접근 방식은 다음과 같은 여러 가지 이점을 제공합니다.

• 익숙한 패턴: Mendix 개발자는 자신이 이미 알고 있는 표준 페이지 레이아웃, 양식 검증 및 스타일링 방법을 사용할 수 있습니다.
• 접근 제어: 역할 기반 접근 제어를 구현하는 것이 더 쉽습니다. Mendix의 내장 보안 기능.
• 양식 검증: 활용 가능 Mendix'의 검증 프레임워크와 오류 처리 메커니즘.
• 반응형 디자인: 자동으로 이점을 얻습니다. Mendix반응형 디자인 기능.

편집 가능한 데이터 처리

이 방법에서는 모든 항목을 편집할 수 있게 됩니다(사용자의 개체 액세스 권한에 따라 다름). 위젯 내에서 업데이트 로직을 구현하는 것이 훨씬 간단해집니다.

• 직접 객체 조작: 더미 객체를 필요로 하지 않고 객체 속성을 직접 수정할 수 있습니다.
• 단순화된 마이크로플로: 변경 사항에 대한 마이크로플로는 간단합니다. 작업에 대한 추가 더미 매개변수가 필요하지 않고 객체를 커밋하기만 하면 됩니다.
• 실시간 업데이트: 복잡한 상태 관리 없이 변경 사항을 UI에 즉시 반영할 수 있습니다.
• 검증 통합: 활용할 수 있음 Mendix내장된 검증 규칙과 오류 처리 기능.

장점

간소화된 유지보수
코드 복잡성이 줄어들고 잠재적인 실패 지점이 줄어들어 위젯 유지 관리가 훨씬 간편해졌습니다.

표준 성능 패턴
지속적으로 개선되는 페이지 매김, 정렬, 필터링 및 지연 로딩에 대한 검증되고 최적화된 관행을 사용합니다. Mendix

디자인 시스템 통합
앱의 디자인 시스템과 위젯 스타일을 더 쉽게 일치시키고, 자동 테마 지원 및 일관된 사용자 경험을 제공합니다.

개발자 친화적 설정
단순화된 설정 Mendix 개발자 - 추가 더미 객체, 복잡한 마이크로플로 구성 또는 내부 위젯 데이터 흐름에 대한 이해가 필요하지 않습니다.

검증된 확장성
혜택 Mendix대규모 데이터 세트에 맞게 확장 가능한 테스트 및 최적화된 목록 처리 기능

접근성 준수
자동으로 상속됩니다 Mendix접근성 기능과 웹 표준 준수

단점

제한된 렌더링 제어
목록 렌더링 옵션에 대한 제어가 감소됨(제한됨) Mendix('의 내장 레이아웃 옵션)

사용자 정의 제약
고도로 사용자 정의된 상호작용이나 레이아웃을 구현할 수 없습니다. Mendix의 표준 기능

고급 기능 제한 사항
복잡한 드래그 앤 드롭, 사용자 정의 정렬 알고리즘 또는 고유한 상호 작용 패턴과 같은 고급 기능을 지원하지 않을 수 있습니다.

접근 방식 3: 여러 위젯

세 번째 옵션은 여러 개의 상호 연결된 위젯을 구축하는 것입니다. 즉, 항목 목록을 렌더링하는 컨테이너 위젯과 개별 할 일 항목을 렌더링하는 하나 이상의 항목 위젯을 구축하는 것입니다. 이 방법은 다음에서 사용할 수 없는 기능이 필요할 때 특히 유용합니다. Mendix고급 드래그 앤 드롭 기능, 사용자 정의 레이아웃 알고리즘 또는 복잡한 항목 간 상호 작용과 같은 기본 제공 목록 구성 요소입니다.

이 접근 방식은 더 나은 계획과 반복적 개발을 촉진합니다. 어떤 부분에 사용자 정의 위젯이 필요하고 어떤 부분에 위젯을 활용할 수 있는지 결정할 수 있습니다. Mendix의 기본 제공 구성 요소입니다. 기능을 반복하면서 전체 시스템을 다시 빌드하지 않고도 필요에 따라 구성 요소를 교체할 수 있습니다.

확장성 및 재사용성 이점

우리의 모든 예를 들어, 컨테이너 위젯을 빌드하면 위의 두 번째 방법에서 사용했던 아이템 위젯을 재사용할 수 있습니다. 그런 다음 컨테이너 위젯 내에 다음과 같은 고급 기능을 추가할 수 있습니다.

• 고급 드래그 앤 드롭: 다방향 드래그, 시각적 피드백이 있는 드롭 존, 복잡한 재정렬 논리
• 사용자 정의 레이아웃 알고리즘: Masonry 레이아웃, 콘텐츠 기반 동적 크기 조정 또는 알고리즘 위치 지정
• 대량 작업: 다중 선택 기능, 일괄 편집 및 복잡한 선택 패턴
• 실시간 협업: 여러 사용자가 동일한 목록을 편집할 때 실시간 업데이트
• 고급 필터링: 사용자 정의 필터 인터페이스, 저장된 필터 사전 설정 및 복잡한 쿼리 빌더

다중 위젯 방식은 더 나은 확장성과 관심사 분리를 제공합니다. 하지만 컴포넌트를 진정으로 재사용 가능하고 포괄적으로 만들려면 구현 복잡성이 증가한다는 점을 고려해야 합니다.
적절한 추상화와 설계가 없으면 재사용성이 제한되고 유지 관리가 더 어려워집니다.

구현 복잡성 고려 사항

또한, 같은 페이지에 있는 여러 위젯 인스턴스가 서로 통신해야 하는 경우 상당한 과제가 발생합니다.

• 상태 동기화: 데이터가 변경될 때 모든 위젯이 동기화 상태를 유지하도록 보장
• 이벤트 조정: 위젯 간 복잡한 이벤트 체인 관리
• 성능 최적화: 불필요한 재렌더링 및 데이터 가져오기 방지
• 오류 처리: 다른 위젯에 영향을 주지 않고 하나의 위젯에서 발생한 오류를 우아하게 처리합니다.
• 놓을 수 있는 영역 구성: Studio Pro에서 놓을 수 있는 영역을 미리 보기 위해 위젯에 미리 보기 모드 구현

국가 관리 과제

위젯 간 신호 전달 및 상태 관리

여러 위젯을 사용할 때 가장 큰 복잡성 중 하나는 위젯 간 통신 및 상태 관리입니다. 위젯이 서로의 상태를 인식해야 하는 경우(예: 사용자가 칸반 보드에서 항목을 한 열에서 다른 열로 드래그하는 경우)에는 강력한 통신 메커니즘이 필요합니다. 한 위젯은 항목을 숨기고 다른 위젯은 표시해야 하지만, 동시에 데이터 일관성을 유지하고 원활한 사용자 피드백을 제공해야 합니다.
이를 위해서는 위젯 간의 정교한 데이터 흐름과 동기화가 필요한데, 이는 간단하지 않으며 특정 구현 기술과 예외 사례에 대한 신중한 고려가 필요합니다.

데이터 흐름 패턴

여러 위젯의 경우, 데이터 제공 방식은 단일 위젯과 유사하지만, 위젯 간 데이터 전달을 위한 안정적인 패턴을 구축해야 합니다. 자식 위젯을 포함하는 컨테이너 위젯을 사용할 수도 있지만, 이해해야 할 중요한 제약 사항이 있습니다.

React 개발자는 부모 구성 요소에서 자식 구성 요소로 속성을 전달할 수 있다고 가정할 수 있지만 이는 불가능합니다. Mendix 플러그인 위젯. 부모 위젯 내부에 다른 위젯을 렌더링하는 경우 Mendix 런타임은 Studio Pro에서 구성된 위젯 설정의 데이터로 전달한 모든 속성을 재정의합니다. 즉, 일반적인 React 애플리케이션처럼 컴포넌트 트리를 통해 동적으로 데이터를 전달할 수 없습니다.

대체 커뮤니케이션 방법

대신 위젯 간에 데이터를 공유하기 위한 대체 방법이 필요합니다.

공유 속성:

• 다른 위젯이 읽을 수 있는 한 위젯의 속성에 쓰기
• 속성이 변경되면 두 번째 위젯은 속성이 변경되었기 때문에 자동으로 다시 렌더링됩니다.
• 자동 반응성을 제공하지만 잦은 업데이트로 인해 성능 문제가 발생할 수 있습니다.
• 선택한 항목이나 필터 값과 같은 간단한 상태 공유에 가장 적합합니다.

React 컨텍스트:

• React 18에서는 상태 관리를 위한 컨텍스트가 도입되었습니다(이전에는 Redux와 같은 타사 라이브러리가 필요했습니다).
• 모든 이후 Mendix 페이지의 위젯은 동일한 React DOM에 의해 렌더링되며 컨텍스트는 위젯 간에 공유될 수 있습니다.
• 한 위젯에서 컨텍스트 공급자를 생성하고 다른 위젯에서 사용할 수 있습니다.
• 복잡한 상태 관리 및 소품 드릴링 방지에 이상적입니다.
• 메모리 누수를 방지하고 적절한 정리를 보장하려면 신중한 설정이 필요합니다.

메시지 게시 API:

• 이 확립된 메커니즘은 다음을 사용합니다. window.postMessage API 페이지 전체에 이벤트를 보내려면
• 위젯은 iframe을 통해서도 위치에 관계없이 이러한 이벤트를 구독할 수 있습니다.
• 위젯 간의 느슨한 결합을 제공하지만 신중한 이벤트 명명 및 페이로드 구조가 필요합니다.
• 일방향 통신 및 이벤트 방송에 최적
• 다양한 페이지 또는 다양한 애플리케이션에서 작업 가능

스타일링 과제

위젯이 여러 개이면 스타일링이 훨씬 더 복잡해집니다. 한 위젯에 CSS 스타일시트가 있고 다른 위젯에서 이를 액세스하려는 경우, 스타일링 아키텍처를 신중하게 계획해야 합니다.

공유 저장소 구조:

• 두 위젯 모두 액세스할 수 있는 더 큰 저장소 구조를 사용하세요.
• 공통 스타일을 공유할 수 있는 빌드 프로세스를 구현합니다.
• 위젯 개발 팀 간의 조정이 필요합니다.
• 버전 동기화 문제로 이어질 수 있습니다.

디자인 시스템 통합:

• 위젯에서 스타일을 완전히 제거하고 이를 디자인 시스템의 책임으로 만드십시오.
• 위젯에서 디자인 시스템의 클래스를 사용하고 디자인 시스템 스타일을 간접 종속성으로 문서화합니다.
• 더 나은 일관성을 제공하지만 성숙한 디자인 시스템이 필요합니다.
• 개별 위젯에 대한 사용자 정의 옵션을 제한할 수 있습니다.

모듈 기반 게시:

• 독립형 위젯이 아닌 모듈로 위젯을 게시하세요
• 이를 통해 위젯 간에 공유할 수 있는 CSS 파일을 내보낼 수 있습니다.
• 더 많은 유연성을 제공하지만 게시 및 배포 프로세스가 복잡해집니다.
• 이해가 필요합니다 Mendix 모듈 개발 패턴

설정 복잡성 및 개발자 경험

럭셔리 Mendix 개발자에게 여러 위젯을 설정하는 것은 단일 위젯을 구성하는 것보다 훨씬 더 어렵습니다. 이러한 복잡성은 여러 가지 방식으로 나타납니다.

구성 종속성:

• 개발자는 하나의 위젯으로 간단한 데이터 소스 구성을 할 수 있습니다.
• 여러 위젯을 사용하는 경우 개발에 사용된 특정 패턴을 이해하고 따라야 합니다.
• 잘못된 구성으로 인해 기능이 손상되거나 성능이 저하될 수 있습니다.

데이터 구조 요구 사항:

• 여러 위젯에는 종종 특정 데이터 구조와 관계가 필요합니다.
• 개발자는 위젯 간의 통신 방식과 각 위젯이 기대하는 데이터를 이해해야 합니다.
• 성공적인 구현을 위해서는 문서화가 매우 중요합니다.

배치 조정:

• 호환성을 보장하기 위해 모든 관련 위젯을 함께 배포해야 합니다.
• 위젯 간 버전 불일치로 인해 런타임 오류가 발생할 수 있습니다.
• 신중한 릴리스 관리 및 테스트 절차가 필요합니다.

디버깅 복잡성:

• 문제는 여러 위젯에 걸쳐 발생할 수 있으므로 디버깅이 더 어려워집니다.
• 개발자는 문제를 해결하기 위해 전체 위젯 생태계를 이해해야 합니다.
• 모든 위젯에 대한 포괄적인 로깅 및 오류 처리가 필요합니다.

성능 고려 사항

여러 위젯을 사용하면 단일 위젯에서는 존재하지 않는 성능 고려 사항이 발생합니다.

• 렌더링 조정: 여러 위젯을 동시에 다시 렌더링하면 성능 병목 현상이 발생할 수 있습니다.
• 메모리 관리: 각 위젯은 자체 상태를 유지하므로 잠재적으로 메모리 사용량이 증가할 수 있습니다.
• 네트워크 최적화: 여러 위젯이 동시에 API 호출을 하면 서버에 과부하가 걸릴 수 있습니다.
• 이벤트 처리: 위젯 간의 복잡한 이벤트 체인은 적절하게 최적화되지 않으면 성능 문제를 일으킬 수 있습니다.

이러한 어려움에도 불구하고, 다중 위젯 방식은 올바르게 구현하면 매우 강력할 수 있습니다. 코드 모듈성과 재사용성을 유지하면서도 정교한 사용자 인터페이스를 구축할 수 있는 유연성을 제공합니다. 핵심은 아키텍처를 사전에 신중하게 계획하고 통신, 스타일링, 데이터 관리를 위한 명확한 패턴을 확립하는 것입니다.

세 가지 접근 방식의 예

비교를 위해, 위의 모든 접근 방식을 사용하여 세 개의 Todo List 쇼케이스 위젯을 구현했습니다. 코드는 주로 Copilot을 사용하여 Vibe 코딩으로 생성했습니다. 요구 사항과 예상 기능을 제시한 후, 예상 결과를 얻기 위해 반복 작업을 진행했습니다. 이 저장소는 쇼케이스 예시일 뿐이며, 프로덕션 환경에서 사용하기 위한 품질 관리를 통과하지 못했습니다.

• 한 가지 코드 예제를 살펴보겠습니다. https://github.com/MeisamMahdian/showcase-todolist-single-widget
• 두 번째 접근 방식 코드 예: https://github.com/MeisamMahdian/showcase-todolist-single-item
• 접근 방식 3 코드 예: https://github.com/MeisamMahdian/showcase-todolist-container-widget

궁극적으로 이 기사가 여러분에게 더 명확한 이해를 제공했기를 바랍니다. Mendix 위젯 아키텍처는 코드 생성을 넘어 플랫폼에 대한 포괄적인 이해가 뛰어난 맞춤형 솔루션을 만드는 데 꼭 필요한 이유를 보여줍니다.