프리젠 테이션 및 컨테이너 구성 요소

2019 년 업데이트:나는 오래 전에이 기사를 썼고 그 이후로 내 견해가 진화했다. 특히,나는 더 이상 이와 같은 구성 요소를 분할하는 것을 제안하지 않습니다. 당신이 당신의 코드베이스에서 자연 찾아내는 경우에,이 패턴은 편리 할 수 있습니다. 그러나 나는 그것이 어떤 필요성없이 그리고 거의 독단적 인 열정으로 너무 여러 번 시행되는 것을 보았다. 그것이 유용하다는 것을 알게 된 주된 이유는 복잡한 상태 저장 논리를 구성 요소의 다른 측면과 분리 할 수 있기 때문입니다. 갈고리는 임의적인 나눗셈 없이 같은 것을 할 수 있게 해 줍니다. 이 텍스트는 역사적인 이유로 그대로 남아 있지만 너무 심각하게 생각하지 마십시오.

반응 응용 프로그램을 작성할 때 대단히 유용한 간단한 패턴이 있습니다. 당신이 잠시 동안 반작용하고 있는 경우에,당신은 아마 이미 그것을 발견했다. 이 기사는 그것을 잘 설명하지만 몇 가지 포인트를 더 추가하고 싶습니다.

당신은 당신이 두 가지 범주로 나눌 경우에 대한 재사용 및 추론하기 훨씬 쉽게 구성 요소를 찾을 수 있습니다. 나는 그것들을 컨테이너 및 프리젠 테이션 구성 요소*라고 부르지 만 뚱뚱하고 마른 체형,똑똑하고 바보 같은 상태,순수한 화면 및 구성 요소 등을 들었습니다. 이 모든 것이 정확히 동일하지는 않지만 핵심 아이디어는 비슷합니다.

내 프레젠테이션 구성 요소:

• 사물이 어떻게 보이는지에 관심이 있습니다.
• 는 내부에 표현 및 컨테이너 구성 요소**를 모두 포함 할 수 있으며 일반적으로 돔 마크 업 및 자체 스타일이 있습니다.
• 종종 이것을 통해 격리 할 수 있습니다.소품.어린이.
• 플럭스 작업 또는 저장소와 같은 나머지 앱에 종속되지 않습니다.
• 데이터 로드 또는 변경 방법을 지정하지 마십시오.
• 소품을 통해 데이터 및 콜백을 독점적으로 수신합니다.
• 자신의 상태가 거의 없습니다.
• 는 상태,수명 주기 후크 또는 성능 최적화가 필요하지 않는 한 기능 구성 요소로 작성됩니다.
• 예:페이지,사이드 바,스토리,사용자 정보,목록.

내 컨테이너 구성 요소:

• 는 사물이 어떻게 작동하는지에 관심이 있습니다.
• 는 표현 구성 요소와 컨테이너 구성 요소를 모두 포함 할 수 있지만 일반적으로 랩핑 사업부를 제외하고는 자체 돔 마크 업이 없으며 스타일이 없습니다.
• 표현 또는 다른 컨테이너 구성 요소에 데이터 및 동작을 제공합니다.
• 플럭스 동작을 호출하고 이를 표현 구성 요소에 콜백으로 제공합니다.
• 는 데이터 원본으로 사용되는 경향이 있으므로 상태 저장이 가능한 경우가 많습니다.
• 는 일반적으로 다음과 같은 고차 구성 요소를 사용하여 생성됩니다.만들기()플럭스 유틸에서,오히려 손으로 작성하는 것보다.
• 예:사용자 페이지,팔로워 사이드 바,스토리 컨테이너,팔로워 사용자 목록.

이 구별을 명확하게하기 위해 다른 폴더에 넣었습니다.

이 접근법의 이점

• 우려의 더 나은 분리. 이 방법으로 구성 요소를 작성하면 앱과 사용자 인터페이스를 더 잘 이해할 수 있습니다.
• 더 나은 재사용. 완전히 다른 상태 소스와 함께 동일한 프레젠테이션 구성 요소를 사용하고 추가로 재사용 할 수있는 별도의 컨테이너 구성 요소로 전환 할 수 있습니다.
• 프레젠테이션 구성 요소는 기본적으로 앱의”팔레트”입니다. 당신은 한 페이지에 넣어 디자이너가 응용 프로그램의 논리를 건드리지 않고 모든 변화를 조정할 수 있도록 할 수 있습니다. 해당 페이지에서 스크린샷 회귀 테스트를 실행할 수 있습니다.
• 이렇게하면 사이드 바,페이지,컨텍스트 메뉴와 같은”레이아웃 구성 요소”를 추출하고이를 사용해야합니다.소품.여러 컨테이너 구성 요소에서 동일한 마크 업 및 레이아웃을 복제하는 대신 자식.

구성 요소는 돔을 방출 할 필요가 없습니다. 그들은 단지 사용자 인터페이스 우려 사이의 구성 경계를 제공 할 필요가있다.

그 활용.

컨테이너를 도입 할 때?

먼저 프레젠테이션 구성 요소만으로 앱 빌드를 시작하는 것이 좋습니다. 결국 당신은 당신이 중간 구성 요소 아래로 너무 많은 소품을 전달하는 것을 알게 될 것이다. 일부 구성 요소가 수신하는 소품을 사용하지 않고 단순히 아래로 전달하고 모든 중간 구성 요소를 아이들이 더 많은 데이터가 필요할 때마다 다시 연결해야한다는 것을 알게되면 일부 컨테이너 구성 요소를 도입 할 수있는 좋은 시간입니다. 이 방법을 사용하면 트리 중간에 관련없는 구성 요소에 부담을주지 않고 리프 구성 요소에 데이터 및 동작 소품을 가져올 수 있습니다.

이것은 리팩토링의 지속적인 프로세스이므로 처음으로 올바르게 얻으려고하지 마십시오. 이 패턴을 실험 할 때 함수를 추출 할 때가 언제인지 알고있는 것처럼 일부 컨테이너를 추출 할 때가 언제인지에 대한 직관적 인 감각을 개발할 것입니다. 내 무료 돌아 오는 지식인 시리즈는 너무 당신을 도울 수 있습니다!

기타 이분법

표현 구성 요소와 컨테이너의 구별은 기술적 인 것이 아니라는 것을 이해하는 것이 중요합니다. 오히려 그것은 그들의 목적에 차이가 있습니다.

대조적으로,여기에 몇 가지 관련이있다(그러나 다른!)기술적 구별:

• 상태 저장 및 상태 비 저장. 컨테이너 구성 요소는 상태 저장되는 경향이 있고 표현 구성 요소는 상태 비저장되는 경향이 있지만 이는 어려운 규칙이 아닙니다. 표현 구성 요소는 상태 저장 일 수 있으며 컨테이너도 상태 비 저장 일 수 있습니다.
• 클래스 및 함수. 반응 0.14 이후 구성 요소는 클래스와 함수로 선언 될 수 있습니다. 기능 구성 요소는 정의하기가 더 간단하지만 현재 클래스 구성 요소에서만 사용할 수있는 특정 기능이 부족합니다. 이러한 제한 중 일부는 미래에 사라질 수 있지만 오늘날 존재합니다. 기능 구성 요소는 이해하기 쉽기 때문에 현재 클래스 구성 요소에서만 사용할 수 있는 상태,수명 주기 후크 또는 성능 최적화가 필요하지 않는 한 해당 구성 요소를 사용하는 것이 좋습니다.
• 순수하고 불순한. 사람들은 동일한 소품과 상태가 주어진 동일한 결과를 반환하도록 보장되는 경우 구성 요소가 순수하다고 말합니다. 순수 구성 요소는 클래스 및 함수로 정의 할 수 있으며 상태 저장 및 상태 비저장이 될 수 있습니다. 이것은 수학적으로 정확한 유형 계층구조인,강력한 타입을 정의합니다. 현재 클래스 만 구성 요소 업데이트()를 정의 할 수 있지만 향후 변경 될 수 있습니다.

프레젠테이션 구성 요소와 컨테이너 모두 이러한 버킷 중 하나에 빠질 수 있습니다. 내 경험에 비추어 볼 때 표현 구성 요소는 상태 비 저장 순수 함수 인 경향이 있으며 컨테이너는 상태 저장 순수 클래스 인 경향이 있습니다. 그러나 이것은 규칙이 아니라 관찰이며,특정 상황에서 의미가 있었던 정반대의 경우를 보았습니다.

제시 및 컨테이너 구성 요소 분리를 교리로 삼지 마십시오. 때로는 중요하지 않거나 선을 그리는 것이 어렵습니다. 특정 구성 요소가 표현형인지 컨테이너인지 확실하지 않은 경우 결정하기에는 너무 이른 것일 수 있습니다. 그것을 땀을 흘리지 마십시오!

예

마이클 찬의 요지는 거의 못 박는다.

추가 읽기

• 돌아 오는 시작하기
• 믹ins 죽은,오래 살아 구성
• 컨테이너 구성 요소
• 원자 웹 디자인
• 릴레이로 페이스 북 뉴스 피드 구축

각주

* 이 문서의 이전 버전에서 나는 그들을”스마트”와”바보”구성 요소라고하지만,이 프리젠 테이션 구성 요소에 지나치게 가혹하고,가장 중요한 것은,정말 자신의 목적의 차이를 설명하지 않았다. 나는 훨씬 더 새로운 용어를 즐길 수,그리고 당신도 할 수 있기를 바랍니다!

**이 문서의 이전 버전에서 나는 프리젠 테이션 구성 요소는 다른 프리젠 테이션 구성 요소를 포함해야한다고 주장했다. 나는 더 이상 이것이 사실이라고 생각하지 않는다. 구성 요소가 프레젠테이션 구성 요소인지 컨테이너인지 여부는 구현 세부 사항입니다. 호출 사이트를 수정하지 않고 프레젠테이션 구성 요소를 컨테이너로 바꿀 수 있어야 합니다. 따라서,프리젠 테이션 및 컨테이너 구성 요소 모두 다른 프리젠 테이션 또는 컨테이너 구성 요소를 잘 포함 할 수 있습니다.