React : 반응물의 소품 수에 상당한 제한이 있습니까?

Question

때때로 많은 양의 성분이있는 성분이 있습니다.

고유 한 문제점이 있습니까?

render() { 

    const { create, update, categories, locations, sectors, workTypes, organisation } = this.props; // eslint-disable-line no-shadow 

    return (
    <div className="job-container"> 
     <JobForm 
     organisationId={organisation.id} 
     userId={user.id} 
     action={action} 
     create={create} 
     update={update} 
     categories={categories} 
     locations={locations} 
     sectors={sectors} 
     workTypes={workTypes} 
     /> 
    </div> 
); 
} 

모범 사례는 무엇입니까?

Answer 1

나는 코드 냄새를 잘 알고 있다고 생각합니다. 함수 (구성 요소)에 많은 입력 (소품)이있을 때마다, 인수 조합의 모든 순열을 사용하여이 구성 요소를 테스트하는 방법에 대해 질문해야합니다. {...this.props}을 사용하면 죽은 부패한 시체에 불어 넣는 바람에 타이핑을 줄입니다.

create 및 update 방법과 제출 방법이 다른 이유는 무엇입니까?

organisationId과 userId은 어떻게 사용합니까? 그것들이 전달 된 create 및 update (또는 submit) 메서드에 전달되어야 할 필요가있는 경우이를 전달하고 onCreate/onUpdate 처리기가 처리기를 제공하도록하지 않는 이유는 무엇입니까? 당신이 props.children이 JobForm 내

<JobForm /* props go here */> 
    <CategoryDroplist categories=this.props.categories /> 
    <LocationDroplist locations=this.props.locations /> 
</JobForm> 

그러나 그 별도의 구성 요소로 잘 될 수있는 별도의 구성 요소 :

어쩌면 JobForm는 다음과 같이 표현한다.

질문에 대답하기에 충분한 정보가 없지만 구성 요소를 더 단순한 것으로 분해하면 소품 수가 줄어들고 냄새도 줄어 듭니다.

Answer 2

자세한 정보 이외에도 문제는 없지만 구성 요소를 근본적으로 유지 관리하는 것이 더 어려워집니다.

좀 더 일반적인 방법은 스프레드 연산자를 사용하여 모든 소품을 속기로 전달하는 것입니다.

<JobForm {...this.props} /> 

문제를 해결하기위한 다른 방법은 대신 구성 할 수 작고, 더 초점을 맞춘 구성 요소로 그것을 분할하여 구성 요소의 책임을 공유하는 것입니다.

Answer 3

지난 몇 년 동안 많은 언어로 기능에 대한 매개 변수의 수를 제한하는 스타일 가이드가있었습니다. ESLint조차 이것과 상태에 관한 규칙을 가지고 있습니다 : "... 각 매개 변수가 무엇인지, 그 유형, 그리고 나타나는 순서를 암기해야하기 때문에 읽기 및 쓰기가 어려울 수 있습니다."

JSX에서도 마찬가지라고 생각합니다. 그리고 JSX는 JS의 DSL이기 때문에 우리는 코드 냄새를 컴파일하고 있습니다.