가장 불평이 없는 React 구성 요소의 쓰기

최근 리액트 코드 생성기를 만들어 "가장 불평할 수 없는 리액트 구성 요소의 쓰기 방법은 무엇입니까?"나는 다시 한 번 의문을 느꼈기 때문에 생각해 보았다.
결론적으로 다음과 같은 형식을 묵인하는 것이 좋다고 생각합니다.

function vs. 합금 함수 ->합금 함수

유형은 기본적으로 VFC를 첨가하여children을 원하는 경우props

에 명확하게 추가

리턴을 생략할 수 있을 때 생략하지 않음->

props destructure를 하지 않는 편이지만 그래도 하는 게 좋을 것 같다

const Hoge: React.VFC<Props> = ({ title }) => {
  return (
    <Fuga title={title} />
  )
}

참고로 전제는 TypeScript를 중요한 전제로 사용해야 한다.(유형이 판단에 관계되기 때문)
그리고 기본적으로 판단축은'이후의 변경이 적다'는 것이다.겉으로는 비슷해 보이지만 언어화할 수 있다는 장점보다는 덜어내고 만지작거릴 때의 변경량을 줄일 수 있는 것을 고르고 싶었다.
다음은 사고의 과정이다.

함수

function Hoge(props) {

}

// vs

const Hoge = (props) => {

}

나는 후자가 다수를 차지한다고 생각한다. 사실 나는 이미 오랫동안 (또는 지금도 습관) 전자function으로 정의했다.
Dan 선생님이 아래 Tweet에서 깨우침을 받았기 때문입니다.
의역
const를 생략하는return의 기법을 반복적으로 정의하기보다는 처음부터 function으로 쓰는 것이 낫지 않겠는가.억지로 다 말로 쓰지 않아도 되는 기법.하하
이런 느낌인가?
이 답변을 받아들인 그는 "확실히 const를 사용했기 때문에 생략할지 말지 선택지가 생겼는데 펀션으로 통일하면.... 무엇보다 저쪽으로 쓰는 게 나을 것 같아서 이유를 물어봐도"단 선생님이 그렇게 말씀하셨다!"이렇게 돌파하자!"그래서 function 기법을 채택했다.

곤란한 일:children의 틀을 찾지 못하다

채용했지만 어려운 것은 React.FC로 정의하지 않으면 children은 Proces의 유형에 속하지 않는다는 것이다.그래서 칠드렌이 필요할 때만 const로 쓰는데 점점 "기법에 편차가 있어서 좋지 않나요"라고 느낀다.
(보충을 먼저 하면 { children?: React.ReactNode } Proops 유형으로 정의할 수 있습니다)
이런 유형의 상황이 있는데, 기본적으로
나는 const Comp: React.FC<Props> = (props)통일하면 변경량이 적어도 된다고 생각한다.

그렇게 생각하지만 앞으로 FC도 children이 없을 거예요.

remove implicitly typed children from React.FC
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/46691
그렇다고 들었습니다.'기본적으로 칠드렌을 뛰어넘는 타입인 것 같은데, 칠드렌의 성분을 반영하는 건지, 틀만 보고 모르는 건지, 그래서 안 좋은 것 같아요'.
현재 React.VFCchildren을 사용하여 프로포즈를 쓰는 형식 정의를 사용하고 있으며, 장래React.FCchildren도 없으면 교체를 추천합니다.이렇게 되면 아까 function 글씨 쓰는 거랑 다를 게 없을 것 같은데 오랜만에 React 추천을 받았어요.VFC를 사용하기로 결정했습니다.

번외편 React.VFC 가입의 이점은 무엇입니까?

이렇게 되면 아까 function 글씨 쓰는 거랑 다를 게 없을 것 같은데 오랜만에 React 추천을 받았어요.VFC를 사용하기로 결정했습니다.
여기서 칠드렌을 목표React.FC로 착용한 몸에 대해 "칠드렌이 없다면 이 착용의 의미는 무엇입니까?"그래서 찾아봤는데

React 구성 요소 이름

뭐,function에서 매개변수 이름도 Proops인데 JSX면 순식간에 "아, React 구성 요소"를 알아볼 수 있어서 문제없지만 틀을 명확하게 덧붙이는 장점이라고 할 수 있죠.

defaultPropos 및 displayName 유형 정의

구체적으로 @types/react의 유형을 보면 아래의 속성이 있는 것 같습니다.
이런 것들을 활용할 때가 있을 수 있기 때문에 묵인된 선택이 좋다고 생각합니다.

interface VoidFunctionComponent<P = {}> {
	(props: P, context?: any): ReactElement<any, any> | null;
	propTypes?: WeakValidationMap<P>;
	contextTypes?: ValidationMap<any>;
	defaultProps?: Partial<P>;
	displayName?: string;
}

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/v16/index.d.ts#L552

이 가능하다, ~할 수 있다,...

const Hoge = () => <Fuga />

vs

const Hoge = () => {
  return (
    <Fuga />
  )
}

저는 개인적으로 후자처럼 모두 쓰는 것이 좋다고 생각합니다.이유는 아까 댄 선생님이 주신 것과 덮는 것, 전자를 쓸 때 스테이트와 함수를 넣고 싶을 때 다시 써야 할 부분이 늘었다는 것이다.그럼 처음부터 다 쓰면?개인적인 소감입니다.

destructure props 여부

const Hoge:React.VFC<Props> = (props) => {
  return (
    <Fuga title={props.title} />
  )
}

// vs

const Hoge:React.VFC<Props> = ({ title }) => {
  return (
    <Fuga title={title} />
  )
}

개인적으로 destructure는 안 하는 게 좋을 것 같아요.
이유는{...props}처럼 전자표를 상대방에게 건네주고 싶을 때가 드물고props의 유형이 바뀌었을 때 하는 부분이 늘었기 때문이다(금형부분 외에 destructure도 해야 한다).props.까지 치면 알림이 뜨기 때문에 타자 속도도 많이 떨어지지 않는다.

추기

나는 이 책을 읽고 클라스네임처럼 아이에게 직접 맡기면 어려운 속성이 있다는 것을 발견했기 때문에 일부 이런 물건을 제거할 때destructure를 사용하는 것이 확실히 편리하다.

const Hoge = ({ className, ... props }) => {}

또한 투명하게 전달되더라도 상술한 내용을 모른 채 교부하는 사고를 방지하기 위해서는 기본적으로destructure가 좋다고 생각합니다.
안녕히 계세요.
destructuring props를 사용하지 않으면 사용하지 않은 props가 보류됩니다
사용하지 않는 프로포즈 대상이 있으면 자동으로 측정할 수 없기 때문이다.
더욱이 destructure를 하면 더 기분이 좋아지고 기분이 좋아져요.

결론은 다시 제기한다

이쪽은 어때!

function vs. 합금 함수 ->합금 함수

유형은 기본적으로 VFC를 첨가하여children을 원하는 경우props

에 명확하게 추가

반환 생략 여부->

props destructure를 하지 않는 편이지만 그래도 하는 게 좋을 것 같다

const Hoge: React.VFC<Props> = ({ title }) => {
  return (
    <Fuga title={title} />
  )
}