왜 나는 단일 파일 구성 요소를 좋아하지 않는가

단일 파일 구성 요소(Single File Components, SFC)는 JavaScript UI 라이브러리에서 사용하는 응용 프로그램 구성 요소로서 각 파일은 여러 면에서 하나의 구성 요소를 나타냅니다.일반적으로 이러한 문서는 HTML 태그, 스타일 태그 및 스크립트 태그가 모두 파일에 있는 HTML 문서와 유사합니다.이것은 Vue 및 Svelte 등 UI 프레임워크의 일반적인 모델입니다.
나는 이 주제에 관한 좋은 문헌을 찾고 있는데, 많은 사람들이 관심의 분리에 대해 이야기하고 있다는 것을 발견했다.나는 MVC를 엄격히 준수하고 너의 코드와 보기를 나의 스타일과 분리하는 것을 제창하는 것이 아니다.나도 구성 요소 파일을 여러 개의 구성 요소로 내보내는 것을 주장하지 않는다.
구성 요소 형식으로서의 SFC의 한계에 대해 말씀드리고 싶습니다.나에게 있어서 이 화제는 갈고리가 유형의 생명 주기 중의 장점을 토론하는 것과 매우 비슷하다.나는 전형적인 중국증권감독위원회를 사용하지 않는 것이 뚜렷한 장점이 있다고 믿는다.

어셈블리 경계
구성 요소 소개하나의 구성 요소여야 하는 논리적 분해는 무엇입니까?이것은 처음에는 누구에게도 뚜렷하지 않다. 설령 네가 더 많은 경험을 얻었다 하더라도, 이것은 여전히 매우 어렵다.
학교에서 그들을 교육시키는 것은 단일 책임 원칙이 하나의 구성 요소가 한 가지 일만 해야 한다는 것을 의미한다고 말할 수도 있다.아마도 이것은 합리적인 계발일 것이다.
나는 초보자가 이것 때문에 크게 놀라고 싶지 않을 수도 있다는 것을 안다.하나의 구성 요소에 너무 많이 붙여서 모든 코드가 앞에 있습니다.도구, 이벤트, 배경 또는 기타 모든 어셈블리 파이핑에는 영향을 주지 않습니다.그냥 간단한 코드예요.
일부 프레임이 모든 VDOM 라이브러리와 같은 전파 시스템 변경과 연관되어 있으면 어셈블리 경계가 매우 엄격한 이유도 있을 수 있습니다.다시 렌더링 여부를 정의합니다.shouldComponentUpdate는 구성 요소의 경계를 교란하여 심각한 영향을 미치는 존재하지 않는 것이 아니다.

So what should make a component?

이상적인 상황에서 개발자에게 의미 있는 일.Svelte의 창시자인 리치 해리스(Rich Harris)는 사라지고 있는 틀에 대해 "틀은 당신의 사고를 조직하는 데 쓰인다"고 말한 바 있다.구성 요소는 그것의 확장자일 뿐입니다.
그래서 중국증권감독위원회가 사실상 잘 처리했어.지금까지 문제 없어요.하지만 깊이 파헤쳐보자.

부품 비용
나는 Cost of Components in UI libraries에 대해 매우 깊이 있는 성능 테스트를 했다.TL;DR은 어느 정도에 VDOM 라이브러리, 예를 들어React는 더 많은 구성 요소로 확장할 수 있지만 다른 라이브러리, 특히React 라이브러리는 확장할 수 없다.그것들은 보통 반응식 표현식을 하위 구성 요소 내부와 동기화해야 하기 때문에 매우 적은 비용을 들여야 한다.
반응 라이브러리와 VDOM 라이브러리가 있는 기준 테스트를 보고 구성 요소를 어떻게 다른 방식으로 사용하는지 보십시오.창설 원가를 테스트할 때, 반응식 라이브러리에서 여러 개의 구성 요소를 사용하는 빈도는 얼마나 됩니까?진정한 응용 프로그램에서 우리는 공교롭게도 매우 많다.

Aside: I wrote a benchmark implementation with a React-Like library using some child components that I wrote with less code than Svelte. I mentioned it in an article and was met with that it wasn't fair that I wasn't making separate components for Svelte. But I couldn't because I wanted to show off Svelte's performance.

이거 가지고 어디로 가야 돼요?SFC를 사용하는 라이브러리가 심오한 구성 요소를 강요하지 않은 것을 축하하는 것은 간단하지 않다.

구성 요소 재구성
재구성에서 가장 비싼 부분은 무엇입니까?나는 개인적으로 경계를 재정립할 것을 건의한다.만약 우리의 이상적인 구성 요소가 우리가 원하는 경계를 선택할 수 있는 구성 요소라면, 나는 우리의 구성 요소가 우리의 편안한 환경에서 성장하고 분열되어야 한다고 건의한다.
React의 어셈블리 모델은 실제로 매우 편리합니다.한 파일에 여러 개의 구성 요소를 포함할 수 있는 것부터 시작합니다.일이 좀 서투르게 변했을 때, 우리는 그것을 끊었다.
템플릿을 더 쉽게 읽을 수 있도록 하는 것도 간단할 수 있다.그저 중복을 줄이기 위해서일지도 모른다.약간 자연스러운 것 같아서, 너는 어떤 것들을 자신의 기능으로 분해하기로 결정했다.내 말은, 어떻게 자바스크립트로 더 적은 코드를 작성합니까?너는 함수를 하나 썼다.
말 바꾸자.당신이 선택한 라이브러리에서 당신이 어떻게 할지 상상해 보세요.예를 들어 그래프 라이브러리를 사용한 다음 정리하는 부작용을 일으키는 구성 요소가 있다고 가정하십시오.

export default function Chart(props) {
  const el = useRef();
  useEffect(() => {
    const c = new Chart(el.current, props.data);
    return () => c.release();
  }, []);
  return (
    <>
      <h1>{props.header}</h1>
      <div ref={el} />
    </>
  )
}

현재, 새로운 수요가 생겼습니다. 브리 enabled 속성을 바탕으로 조건부로 적용해야 합니다.
이 연습을 마치고 단독 구성 요소로 사용한다면, 조건을 적용하려면 코드의 보기와 명령 부분 (불러오기, 업데이트, 발표) 에 적용해야 한다는 것을 깨달아야 합니다.

export default function Chart(props) {
  const el = useRef();
  useEffect(() => {
    let c;
    if (props.enabled) c = new Chart(el.current, props.data);
    return () => if (c) c.release();
  }, [props.enabled]);

  return (
    <>
      <h1>{props.header}</h1>
      {props.enabled && <div ref={el} />}
    </>
  )
}

또는 React를 사용하면 논리가 기본적으로 변하지 않는 다른 구성 요소로 분해하기만 하면 된다.

function Chart(props) {
  const el = useRef();
  useEffect(() => {
    const c = new Chart(el.current, props.data);
    return () => c.release();
  }, []);
  return <div ref={el} />;
}

export default function ChartContainer(props) {
  return (
    <>
      <h1>{props.header}</h1>
      {props.enabled && <Chart data={props.data} />}
    </>
  )
}

이것은 간단한 예이지만, 이러한 한 번에 여러 가지를 변경하는 방법도 Hooks/Composition API/Svelte$가 클래스의 생명 주기보다 더욱 치밀하고 유지보수하기 쉬운 코드를 만들 수 있는 원인이다.하지만 여기서 질문할 내용은 템플릿과 JavaScript의 동일한 차이점입니다.
부작용뿐만 아니라 끼워 넣은 상태에도 적용된다.React 방법의 가장 좋은 점은 그것이 비승낙적이라는 것이다.나는 새로운 서류를 만들 필요가 없다.나는 아직도 이 조립품이 어떻게 작동하는지 배우고 있다.만약 수요가 다시 변화가 발생하면 어떻게 합니까?내가 비결을 배운 풋내기일 뿐이라면?

중국증권감독위원회의 한계성
파일을 단일 구성 요소로 제한하는 문제는 단일 단계의 상태/생명 주기만 처리할 수 있다는 데 있다.그것은 자라거나 쉽게 바꿀 수 없다.경계가 일치하지 않을 때 추가 코드가 발생하고, 여러 파일을 불필요하게 분할할 때 인지적 비용이 발생합니다.
SFCs 라이브러리에서는 중첩 구문을 구현하는 방법을 연구할 수 있습니다.대다수의 도서관.비중국증권감독위원회 구성원이라도 이 점을 지지하지 않는다.예를 들어 React는 갈고리를 끼워 넣거나 조건에 두는 것을 허용하지 않는다.대부분의 SFC에서는 템플릿에 중첩된 JavaScript를 사용할 수 없습니다.MarkoJS는 내가 알고 있는 유일한 지원Macros(중첩 구성 요소)과 inline JS의 SFC일 수 있지만 이것은 표준이 아니다.
아마도 이것은 아직 중요하지 않다고 생각할 것이다. 그러나 초보자에게는 처음부터 유지보수성을 고려한 응용 프로그램 체계 구조가 전문가에게 가치가 있다.그것은 그것들에 따라 점차 증가할 것이다.이것이 바로 내가 클래스 구성 요소가 아닌 갈고리를 좋아하는 것처럼 SFC를 좋아하지 않는 이유이다.
이것이 바로 SolidJS이 응용 프로그램이 성장할 때 가장 좋은 체험을 하도록 설계된 이유이다.그것의 부품은 이상에 부합된다.이것은 두 세계 중 가장 좋은 것이다.그것은 VDOM 라이브러리 같은 불필요한 구성 요소를 만들도록 강요하지는 않지만, 그렇게 하는 것을 제한하지는 않을 것이다.템플릿의 중첩 상태와 효과를 지원하기 때문에 필요에 따라 증가합니다.
다시 말하면 위에서 언급한 방법 외에 당신은 효과와 상태를 삽입할 수 있다.ref 콜백을 사용하여 이러한 인라인 사용자 정의 명령을 실행할 수도 있습니다.

export default function Chart(props) {
  return (
    <>
      <h1>{props.header}</h1>
      {
        props.enabled && <div ref={el =>
          createEffect(() => {
            const c new Chart(el.current, props.data);
            onCleanup(() => c.release());
          })
        } />
      }
    </>
  )
}

Solid는 라이프 사이클에 독립적인 선언적 데이터, 사라진 구성 요소, JSX가 지원하는 템플릿, 고성능 입자 반응성을 통해 이를 구현합니다.
갈고리와 조합 API는 성명성 데이터 모드의 가죽과 털만 건드렸다.가장 익숙하지만 전혀 다른 JS(TypeScript) 프레임을 살펴보자.
https://github.com/ryansolid/solid