Language-tools: Svelte 구성 요소 소품/이벤트/슬롯 입력

합리적으로 보이지만 실제로 런타임에 슬롯을 삽입할 수 있는 것에 대한 Svelte 문제가 있습니다. https://github.com/sveltejs/svelte/issues/2588 및 이를 구현하는 PR https://github.com/sveltejs/svelte/pull/4296 , 중복되거나 적어도 일부 기회가 있는 것처럼 느껴집니다. 인터페이스를 정렬합니다(합의가 있는 경우 위의 PR에 여전히 몇 가지 해결되지 않은 질문이 있습니다).

PR 링크 주셔서 감사합니다. 생성자를 약간 다르게 입력해야한다는 점에서 우리와 관련이있는 것 같습니다. 그러나 이것은 템플릿 수준에서 유형 검사의 들여 쓰기라고 생각합니다.

흥미로운.
나는 우리가 다음과 같은 것을 할 수 있는지 궁금합니다.

<script lang="ts" generic="T"> 
    type T = unknown
    export let items: T[]
    let item:T = items[0]
</script>
<slot b={item}></slot>

typecheck 동안 type T = unknown 를 제거하고 대신 구성 요소에 일반 인수로 추가합니다.

//...
render<T>() {
    export let items: T[]
    let item:T = items[0]
}

render 함수에 추가하는 것이 좋습니다!

나는 우리가 와 같은 결과를 얻을 수 있다고 생각한다

<script lang="ts">
    interface ComponentDef<T> {
       ...
    } 
    type T = unknown
    export let items: T[]
    let item:T = items[0]
</script>
<slot b={item}></slot>

인터페이스 정의에서 T 를 추출합니다.

귀하의 솔루션을 사용하면 "내 소품과 슬롯 사이의 일반적인 관계를 원합니다"의 경우 더 적게 입력해야 하지만 이는 좋은 일입니다. 한편으로는 "예, 둘 다 추가할 수 있습니다"라고 생각하지만 다른 한편으로는 API 표면을 너무 많이 확장하는 것 같은 느낌이 듭니다(같은 작업을 다른 방식으로 수행할 수 있음) - 확실하지 않습니다.

interface ComponentDef<T>{ props: {} } 를 작성하고 내 수출품의 각 항목과 정렬하고 싶지 않습니다. Svelte는 React와 비교하여 입력된 문자를 줄이는 데 매우 뛰어나며 이는 한 걸음 뒤로 물러난 것처럼 느껴집니다. 특히, 모든 내보내기 유형을 props로 복제해야 하므로 재미가 없습니다(그리고 자주 문제를 일으킬 수 있음).

나는 @halfnelson 의 사고 방식을 좋아합니다. 내보내기는 소품으로 감지되어야 합니다. 모듈이 한 번 어떻게 생겼는지 모르겠습니다.

관련 문제에서 읽은 또 다른 빠른 문제: @template 옵션을 포함하여 JSDoc 주석을 사용하여 항목을 입력하는 데 문제가 없었습니다.

JSDoc(HTML 내에서 JSDoc을 사용하는 경우에도)에 대해 열린 마음을 유지해야 하지만 WebStorm을 통해 사용하든 VS Code를 통해 사용하든 단순히 TypeScript로 표현력이 부족하다는 점을 경고해야 합니다. 예를 들어 true 유형을 구현하지 않습니다. 인덱스 유형을 수행하지 않는다고 확신합니다. 그리고 내가 기억한다면, 당신은 Record<keyof X, any> 도 가질 수 없습니다. 나는 그것으로 계속 벽에 부딪친다. @template 도 작동했지만 꽤 제한적이었습니다. 그리고 IDE에 따라서도 다르게 잘 작동한다고 생각합니다.

제네릭 유형에 (jsx) 요소를 전달하는 것은 유효한 svelte 템플릿 구문이 아니기 때문에 나에게 적합하지 않습니다. 제네릭은 속성에 의해 구동되기 때문에 필요하지 않아야 합니다. 슬롯/이벤트에만 제네릭 종속성을 도입하는 방법을 생각할 수 없습니다. jsx 요소에 제네릭을 전달하는 입력 속성에 의해 구동되는 경우 TS가 이를 유추하는 방식으로 svelte2tsx 코드를 생성할 수 있기 때문에 필요하지 않습니다.

타이핑 오버헤드에 관하여: 이것은 정확하지만 제네릭을 사용하거나 명시적으로 이벤트/슬롯을 입력하려는 상황에서만 필요합니다. 이론상으로 우리는 이 모든 것을 스스로 추론할 수 있지만 구현하기가 매우 어렵습니다. 구현하기 어려운 문제의 예는 #263과 같은 고급 슬롯 시나리오에 대한 지원과 가능한 모든 구성 요소 이벤트를 수집하는 것입니다(사용자가 createEventDispatcher 만 사용하면 쉽지만 다음과 같은 기능을 가져올 수도 있습니다. createEventDispatcher 항목을 래핑합니다).

일반적으로 사람들이 그 중 하나만 정의하고 나머지는 정의하지 않으려는 상황이 많이 있으므로 Svelte의 "유형을 덜" 유지하기 위해 모든 다양한 옵션을 제공해야 할 수도 있습니다.

이것은 다음을 의미합니다.

• ComponentDef 는 필요할 때만 사용할 수 있는 제품입니다.
• ComponentEvents 는 이벤트 입력 전용입니다.
• ComponentSlots 는 입력 슬롯 전용입니다.
• 제네릭만 필요한 경우 <script generic="T"> 와 같은 구성
• ComponentEvents/ComponentSlots/generic="T" 의 조합

@shirakaba JSDoc 유형 지원이 typescript만큼 기능이 풍부할 필요는 없습니다. 나는 많은 사람들이 그것으로 제네릭 컴포넌트를 입력할 것이라고 의심합니다. 또한 typescript의 언어 서비스를 사용하고 있기 때문에 많은 고급 유형을 typescript 파일에서 쉽게 가져올 수 있습니다.

슬롯 소품 유형 검사에 대해 약간의 해킹이 있지만 이것이 좋은 개발자 경험으로 이어질지 모르겠습니다. 사용자 유형 구성 요소가 다음과 같은 경우:

interface ComponentDef {
      slots: { default: { item: string } }
  }

우리는 클래스를 생성할 수 있습니다

class DefaultSlot extends Svelte2TsxComponent<ComponentDef['slots']['default']>{ }

기본 슬롯을 다음으로 변환

<DeafaultSlot />

(사용자로서만 참여) TypeScript로 작업하는 동안 어쨌든 많은 작업을 수행해야 하기 때문에 추가 입력은 문제가 되지 않습니다.

interface vs. generic prop의 경우 변수가 소비자에게만 노출되는 경우가 있으므로 prop을 지원하는 DX가 더 좋습니다. 그러나 그 메모에서 generic="T" export type T 를 지원할 수 있습니까?

이것은 사람들을 혼란스럽게 할 수 있는 잘못된 TS 구문입니다. 또한 Svelte 구성 요소가 컴파일할 수 없는 상태인 경우 수행되지 않는 추가 변환 단계를 수행해야 합니다. 이 경우 언어 도구는 스크립트에 있는 것으로 돌아가며 이 잘못된 구문을 갖게 됩니다. 그래서 저는 반대합니다.

이해 했어요. 오래 머물지 않지만 잘못된 구문이거나 "정의되지 않은/알 수 없는 유형" 오류입니까? TypeScript의 컴파일러가 두 가지 경우를 어떻게 처리하는지 몰라서 질문합니다. 나는 script 태그에 사용자 정의 속성을 추가하는 것에 대해 예약이 있습니다. 특히 "generic"과 같은 이름을 사용합니다. :)

대체로 나에게 이것은 좋은 기능이며 구성 요소를 사용할 때 사용자가 내보낸 변수를 강제로 입력하도록 하는 것이 좋습니다(더 읽기 쉬운 코드).

export type T; 를 입력하면 TS에서 구문 오류가 발생합니다. 또한 제약 조건을 공식화하는 방법은 무엇입니까? export type T extends string; 는 더 많은 구문 오류를 발생시킵니다. 사용자 지정 속성에 대한 귀하의 예약을 완전히 이해하지만 가장 방해가 적은 방법이라고 생각합니다. 다른 방법은 T1 또는 T2 와 같은 예약된 유형 이름을 갖는 것이지만 충분히 유연하지 않습니다(제약 조건을 추가하는 방법?).

대안은 ComponentDef 를 통해 전체 구성 요소를 입력하는 것입니다. 여기에서 시작 게시물의 예제와 같이 제네릭을 자유롭게 추가할 수 있습니다. 그러나 이것은 더 많은 타이핑을 요합니다.

사람들이 이것에 대해 매우 다른 의견을 가지고 있고 더 많은 옵션을 배치하는 것이 토론에서 분명해졌습니다( ComponentDef , 속성으로 일반 props, ComponentEvents 만 입력) 그들은 같은 일을 하는 다른 방법을 소개하지만 대부분을 행복하게 만듭니다.

나는 이것을 놓쳤을 수도 있지만 그것을 옵션으로 분할하고 있습니까?

<script>
  import type { Foo } from './foo';
  export let items: Foo[];
  interface ComponentSlots<T> {}
  interface ComponentEvents<T> {}
</script>

그러면 대부분의 경우 타이핑 오버헤드가 줄어들까요?

네, 가능합니다.

@dummdidumm 그 동안 interface ComponentSlots {} (제네릭 지원 여부에 관계없이) 지원 작업이 가능합니까? 아니면 여기에서 논의된 내용과 모순되는 도입입니까?

그렇지는 않겠지만 구현을 계속하기 전에 제안된 솔루션에 대해 커뮤니티와 다른 유지 관리자로부터 더 많은 피드백을 얻기 위해 먼저 RFC를 작성하고 싶습니다. 일단 합의가 되면 그러한 것들을 구현하기 시작할 것입니다.

@joelmukuthu btw 인터페이스 지원을 원하는 이유는 무엇입니까? 슬롯에 대한 유형 추론을 개선했습니다. 여전히 작동하지 않는 경우가 있습니까? 그렇다면 귀하의 사례를 듣고 싶습니다.

이제 이 주제에 대한 RFC를 만들었습니다. https://github.com/sveltejs/rfcs/pull/38
API에 대한 논의는 그곳에서 계속되어야 합니다.

@dummdidumm 응답이 느려서 죄송합니다. 저는 제 유스 케이스의 경우 실제로 제네릭에 대한 지원이 필요하다는 것을 깨달았습니다. 슬롯에 대한 유형 추론은 매우 잘 작동합니다!

이것은 엄청날 것입니다! 나는 현재 슬롯 속성을 사용하는 것이 항상 any라는 것이 슬프다.

이상하게도 사용하는 구성 요소가 프로젝트 내에 있고 TS도 사용하는 경우 이 시점에서 슬롯 유형을 아주 멋지게 유추할 수 있습니다.

아마도 여기서 잘못된 용어를 사용하고 있는 것 같습니다. 아니면 제가 뭔가 잘못한 것뿐입니다.

내가 할 수 있기를 바라는 것의 예:

```html


{option.myLabelProp}

알겠습니다. 예, 지금은 불가능하므로 any[] 로 돌아가야 합니다. 이것이 string[] 만 허용한다면 슬롯은 string 로 입력됩니다. 이는 "유형을 유추할 수 있음"을 의미합니다.

Mark Volkmann의 "Svelte and Sapper in Action"에서 만난 유형 검사 구성 요소에 대한 좋은 임시 솔루션은 $$props와 함께 React prop-types 라이브러리를 사용하는 것입니다.

이것은 예를 들어 할 일 항목에 대한 코드입니다.

import PropTypes from "prop-types/prop-types";

const propTypes = {
    text: PropTypes.string.isRequired,
    checked: PropTypes.bool,
};

// Interface for Todo items
export interface TodoInterface {
    id: number;
    text: string;
    checked: boolean;
}

PropTypes.checkPropTypes(propTypes, $$props, "prop", "Todo");

Todo의 소품을 확인하고 무언가가 꺼져 있으면 오류가 발생하는 동안 Todo 항목에 대한 인터페이스도 갖고 싶습니다. 따라서 VSCode에서 정적 유형 검사와 자동 완성 기능을 사용할 수 있습니다. 이것은 위에서 정의한 인터페이스를 사용하여 달성됩니다. 이것의 명백하고 중요한 단점은 여기에 중복 코드가 필요하다는 것입니다. propTypes 개체에서 인터페이스를 정의할 수 없으며 그 반대의 경우도 마찬가지입니다.

저는 아직 자바스크립트로 시작하고 있으므로 이 중 하나라도 잘못된 경우 수정해 주세요.

유형 검사는 런타임 시 정적 검사와 props 유형 검사 모두에서 생산적인 코드베이스에 반드시 있어야 한다고 생각합니다.

(인터페이스는 context='module'에 정의되어 구성 요소 기본 내보내기와 함께 내보낼 수 있지만 간결함을 위해 해당 부분을 생략했습니다.)

편집: 소품 유효성 검사 이외의 다른 용도로는 이것을 시도하지 않았습니다. 슬롯/이벤트에서도 작동하는지 알려주세요!