React: RFC: React 18의 사용자 정의 요소 속성/속성 계획

에 만든 2017년 10월 24일 · 129코멘트 · 출처: facebook/react

이것은 주소 #7249를 의미합니다. 이 문서는 React가 사용자 정의 요소의 속성과 속성을 처리하는 데 사용할 수 있는 다양한 접근 방식의 장단점을 설명합니다.

목차/요약

배경
제안
- 옵션 1: 속성만 설정
- 장점
  - 이해/구현 용이
  - 미래 전역 속성과의 충돌 방지
  - 사용자 정의 요소 "업그레이드" 활용
  - 다른 React 구성 요소처럼 취급되는 사용자 정의 요소
- 단점
  - 아마도 브레이킹 체인지
  - 속성을 설정하려면 참조가 필요합니다.
  - 서버 측 렌더링이 어떻게 작동하는지 명확하지 않음
- 옵션 2: 가능한 경우 속성
- 장점
  - 핵심 변경 사항
- 단점
  - 개발자는 휴리스틱을 이해해야 합니다.
  - 속성으로 폴백하면 미래 전역과 충돌할 수 있습니다.
- 옵션 3: 인장으로 속성 구별하기
- 장점
  - 개발자가 선택할 수 있는 핵심 변경 사항
  - 다른 라이브러리가 속성/속성을 처리하는 방식과 유사
  - 시스템이 명시적입니다.
- 단점
  - 새로운 구문입니다
  - 서버 측 렌더링이 어떻게 작동하는지 명확하지 않음
- 옵션 4: 속성 개체 추가
- 장점
  - 시스템이 명시적입니다.
  - 확장 구문은 이벤트 처리 문제도 해결할 수 있습니다.
- 단점
  - 새로운 구문입니다
  - 획기적인 변화일 수 있습니다
  - 이전 제안보다 더 큰 변화일 수 있습니다.
- 옵션 5: 맞춤 요소를 사용하기 위한 API
- 장점
  - 시스템이 명시적입니다.
  - 핵심 변경 사항
  - 반응에 관용적
- 단점
  - 복잡한 구성 요소의 경우 많은 작업이 필요할 수 있습니다.
  - 번들 크기가 커질 수 있음
  - 구성은 구성 요소와 보조를 맞춰야 합니다.

배경

React는 사용자 정의 요소에 데이터를 전달하려고 할 때 항상 HTML 속성을 사용하여 전달합니다.

<x-foo bar={baz}> // same as setAttribute('bar', baz)

속성은 문자열로 직렬화되어야 하므로 이 접근 방식은 전달되는 데이터가 개체 또는 배열인 경우 문제를 생성합니다. 이 시나리오에서는 다음과 같이 끝납니다.

<x-foo bar="[object Object]">

이에 대한 해결 방법은 ref 를 사용하여 속성을 수동으로 설정하는 것입니다.

<x-foo ref={el => el.bar = baz}>

이 해결 방법은 오늘날 제공되는 대부분의 사용자 지정 요소가 노출된 모든 속성을 지원하는 JavaScript 속성을 자동으로 생성하는 라이브러리로 작성되었기 때문에 약간 불필요하게 느껴집니다. 그리고 바닐라 사용자 정의 요소를 수동으로 작성하는 사람도 이 방법을 따르는 것이

이 문서는 이를 가능하게 하기 위해 어떻게 React를 업데이트할 수 있는지에 대한 몇 가지 제안을 간략하게 설명합니다.

제안

옵션 1: 속성만 설정

속성이나 속성을 설정해야 하는지 결정하는 대신 React는 항상 사용자 정의 요소에 속성을 설정할 수 있습니다. React는 속성이 요소에 미리 존재하는지 확인 하지 않습니다 .

예시:

<x-foo bar={baz}>

위의 코드는 React가 x-foo 요소의 .bar 속성을 baz 값과 동일하게 설정하도록 합니다.

camelCased 속성 이름의 경우 React는 현재 tabIndex 같은 속성에 사용하는 것과 동일한 스타일을 사용할 수 있습니다.

<x-foo squidInk={pasta}> // sets .squidInk = pasta

장점

이해/구현 용이

이 모델은 단순하고 명시적이며 React의 "JavaScript-centric API to DOM" 과 밀접하게 연관

Polymer 또는 Skate와 같은 라이브러리로 생성된 모든 요소는 노출된 속성을 뒷받침하는 속성을 자동으로 생성합니다. 이러한 요소는 모두 위의 접근 방식으로 "정상 작동"해야 합니다. 바닐라 구성 요소를 직접 작성하는 개발자는 속성을 사용하여 속성 을 지원하는 것이 좋습니다. 이는 HTML5 요소( <video> , <audio> 등)가 얼마나 현대적인지 (즉, <input> 와 같은 이상한 것이 아님)을 반영하기 때문입니다. 구현되었습니다.

미래 전역 속성과의 충돌 방지

React가 사용자 정의 요소에 속성을 설정하면 HTML의 향후 버전이 비슷한 이름의 속성을 제공하여 문제를 일으킬 위험이 항상 있습니다. 이 문제는 사양 작성자와 논의 되었지만 문제에 대한 명확한 해결책은 없습니다. 속성을 완전히 피하면(개발자가 ref 사용하여 명시적으로 속성을 설정하는 경우 제외) 브라우저가 더 나은 솔루션을 제공할 때까지 이 문제를 피할 수 있습니다.

사용자 정의 요소 "업그레이드" 활용

사용자 정의 요소는 페이지에서 느리게 업그레이드 될 수 있으며 일부 PRPL 패턴은 이 기술에 의존합니다. 업그레이드 프로세스 동안 사용자 정의 요소는 React에 의해 전달된 속성에 액세스할 수 있으며(해당 속성이 정의가 로드되기 전에 설정되었더라도) 이를 사용하여 초기 상태를 렌더링할 수 있습니다.

다른 React 구성 요소처럼 취급되는 사용자 정의 요소

React 구성 요소가 데이터를 서로 전달할 때 이미 속성을 사용합니다. 이렇게 하면 사용자 지정 요소가 동일한 방식으로 작동합니다.

단점

아마도 브레이킹 체인지

개발자가 속성 API만 있는 바닐라 사용자 정의 요소를 수동으로 작성했다면 코드를 업데이트해야 하며 그렇지 않으면 앱이 중단됩니다. 수정 사항은 ref 를 사용하여 속성을 설정하는 것입니다(아래 설명 참조).

속성을 설정하려면 참조가 필요합니다.

속성이 선호되도록 동작을 변경하면 개발자가 사용자 정의 요소에 속성을 명시적으로 설정하기 위해 ref 를 사용해야 함을 의미합니다.

<custom-element ref={el => el.setAttribute('my-attr', val)} />

이것은 개발자가 속성을 설정하기 위해 ref 가 필요한 현재 동작의 반전입니다. 개발자는 사용자 정의 요소에 속성을 설정할 필요가 거의 없어야 하므로 이는 합리적인 절충안으로 보입니다.

서버 측 렌더링이 어떻게 작동하는지 명확하지 않음

이 모델이 서버 측 렌더링 사용자 정의 요소에 어떻게 매핑되는지는 확실하지 않습니다. React는 속성이 유사한 이름의 속성에 매핑된다고 가정하고 서버에서 설정을 시도할 수 있지만 이것은 방탄이 아니며 camelCased 속성 -> dash-cased 속성과 같은 것에 대한 경험적 방법이 필요할 수 있습니다.

옵션 2: 가능한 경우 속성

런타임에 React는 사용자 정의 요소에 속성이 있는지 감지하려고 시도할 수 있습니다. 속성이 있으면 React가 이를 사용하고, 그렇지 않으면 속성 설정으로 대체합니다. 이것은 Preact가 사용자 정의 요소를 처리하는 데 사용하는 모델입니다.

의사 코드 구현:

if (propName in element) {
  element[propName] = value;
} else {
  element.setAttribute(propName.toLowerCase(), value);
}

가능한 단계:

요소에 정의된 속성이 있으면 React가 이를 사용합니다.
요소에 정의되지 않은 속성이 있고 React가 기본 데이터(문자열/숫자/부울)를 전달하려고 하면 속성을 사용합니다.
- 대안: 경고하고 설정하지 마십시오.
요소에 정의되지 않은 속성이 있고 React가 개체/배열을 전달하려고 하면 속성으로 설정됩니다. 이것은 some-attr="[object Object]"가 유용하지 않기 때문입니다.
- 대안: 경고하고 설정하지 마십시오.
요소가 서버에서 렌더링되고 React가 문자열/숫자/부울을 전달하려고 하면 속성을 사용합니다.
요소가 서버에서 렌더링되고 React가 개체/배열을 전달하려고 하면 아무 작업도 수행하지 않습니다.

장점

핵심 변경 사항

속성만 인터페이스로 사용하는 사용자 정의 요소를 생성할 수 있습니다. 이 작성 스타일은 권장 되지 않지만 관계없이 발생할 수 있습니다. 사용자 정의 요소 작성자가 이 동작에 의존하는 경우 이 변경 사항은 중요하지 않습니다.

단점

개발자는 휴리스틱을 이해해야 합니다.

개발자는 React가 요소를 로드하기 위해 선택한 방법에 따라 속성 대신 속성을 설정할 때 혼란스러울 수 있습니다.

속성으로 폴백하면 미래 전역과 충돌할 수 있습니다.

Sebastian 은 in 를 사용하여 사용자 지정 요소의 속성이 있는지 확인하는 데 실수로 슈퍼클래스(HTMLElement)의 속성을 감지할 수 있다는 우려 를

이 문서의 이전 에

옵션 3: 인장으로 속성 구별하기

React는 사용자 정의 요소에 대한 속성을 계속 설정할 수 있지만 개발자가 대신 명시적으로 속성을 설정하는 데 사용할 수 있는 인장을 제공합니다. 이것은 Glimmer.js에서 사용하는 접근 방식 과 유사합니다.

희미한 예:

<custom-img @src="corgi.jpg" @hiResSrc="[email protected]" width="100%">

위의 예에서 @ sigil은 src 및 hiResSrc 가 속성을 사용하여 사용자 정의 요소에 데이터를 전달하고 width 가 속성 문자열로 직렬화되어야 함을 나타냅니다.

React 구성 요소는 이미 속성을 사용하여 데이터를 서로 전달하기 때문에 sigil을 사용할 필요가 없습니다(그렇다면 작동하지만 중복될 뿐입니다). 대신 JavaScript 속성을 사용하여 사용자 정의 요소에 데이터를 전달하기 위한 명시적 명령으로 주로 사용됩니다.

이 접근 방식을 제안한 Preact 의 @developit에게 h/t를

장점

개발자가 선택할 수 있는 핵심 변경 사항

기존의 모든 React + 사용자 정의 요소 앱은 그대로 계속 작동합니다. 개발자는 새로운 sigil 스타일을 사용하도록 코드를 업데이트할지 여부를 선택할 수 있습니다.

다른 라이브러리가 속성/속성을 처리하는 방식과 유사

Glimmer와 유사하게 Angular와 Vue 모두 속성과 속성을 구별하기 위해 수정자를 사용합니다.

뷰 예시:

<!-- Vue will serialize `foo` to an attribute string, and set `squid` using a JavaScript property -->
<custom-element :foo="bar” :squid.prop=”ink”>

각도 예:

<!-- Angular will serialize `foo` to an attribute string, and set `squid` using a JavaScript property -->
<custom-element [attr.foo]="bar” [squid]=”ink”>

시스템이 명시적입니다.

개발자는 properties-if-available 접근 방식과 같은 경험적 방법에 의존하는 대신 원하는 것을 정확히 React에 말할 수 있습니다.

단점

새로운 구문입니다

개발자는 사용 방법을 배워야 하며 이전 버전과의 호환성을 확인하기 위해 철저히 테스트해야 합니다.

서버 측 렌더링이 어떻게 작동하는지 명확하지 않음

sigil이 비슷한 이름의 속성을 사용하도록 전환해야 합니까?

옵션 4: 속성 개체 추가

React는 작성자가 명시적으로 데이터를 속성으로 전달할 수 있도록 하는 추가 구문을 추가할 수 있습니다. 개발자가 이 속성 개체를 사용하지 않는 경우 해당 데이터는 JavaScript 속성을 사용하여 전달됩니다.

예시:

const bar = 'baz';
const hello = 'World';
const width = '100%';
const ReactElement = <Test
  foo={bar} // uses JavaScript property
  attrs={{ hello, width }} // serialized to attributes
/>;

이 아이디어는 원래 Skate.js 의 작성자인 @treshugart가 제안 했으며 val 라이브러리에서 구현되었습니다.

장점

시스템이 명시적입니다.

개발자는 properties-if-available 접근 방식과 같은 경험적 방법에 의존하는 대신 원하는 것을 정확히 React에 말할 수 있습니다.

확장 구문은 이벤트 처리 문제도 해결할 수 있습니다.

참고: 이것은 이 문서의 범위를 벗어나지만 언급할 가치가 있습니다. :)

문제 #7901 은 선언적 이벤트 핸들러가 사용자 정의 요소에 추가될 때 React가 합성 이벤트 시스템을 우회하도록 요청합니다. 사용자 정의 요소 이벤트 이름은 임의의 문자열이므로 어떤 방식으로든 대문자로 사용할 수 있습니다. 오늘날 합성 이벤트 시스템을 우회하려면 JSX에서 addEventListener 이벤트 이름을 매핑하기 위한 경험적 방법을 찾아야 합니다.

// should this listen for: 'foobar', 'FooBar', or 'fooBar'?
onFooBar={handleFooBar}

그러나 속성을 허용하도록 구문이 확장되면 이벤트도 허용하도록 확장될 수 있습니다.

const bar = 'baz';
const hello = 'World';
const SquidChanged = e => console.log('yo');
const ReactElement = <Test
  foo={bar}
  attrs={{ hello }}
  events={{ SquidChanged}} // addEventListener('SquidChanged', …)
/>;

이 모델에서 변수 이름은 이벤트 이름으로 사용됩니다. 휴리스틱이 필요하지 않습니다.

단점

새로운 구문입니다

개발자는 사용 방법을 배워야 하며 이전 버전과의 호환성을 확인하기 위해 철저히 테스트해야 합니다.

획기적인 변화일 수 있습니다

구성 요소가 이미 attrs 또는 events 라는 속성에 의존하는 경우 손상될 수 있습니다.

이전 제안보다 더 큰 변화일 수 있습니다.

React 17의 경우 (이전 제안 중 하나와 같이) 점진적인 변경을 수행하고 이 제안을 나중에 더 큰 리팩터링을 위해 고려해야 할 사항으로 배치하는 것이 더 쉬울 수 있습니다.

옵션 5: 맞춤 요소를 사용하기 위한 API

이 제안은 React 팀의 @sophiebits 와 @gaearon 이 제안했습니다.

React는 요소의 동작을 구성 개체와 매핑하는 사용자 정의 요소를 사용하기 위한 새 API를 만들 수 있습니다.

의사 코드 예:

const XFoo = ReactDOM.createCustomElementType({
  element: ‘x-foo’,
  ‘my-attr’: // something that tells React what to do with it
  someRichDataProp: // something that tells React what to do with it
});

위의 코드는 제공하는 구성에 따라 사용자 지정 요소에 데이터를 전달하는 방법을 알고 있는 프록시 구성 요소 XFoo 를 반환합니다. 사용자 지정 요소를 직접 사용하는 대신 앱에서 이 프록시 구성 요소를 사용합니다.

사용 예:

<XFoo someRichDataProp={...} />

장점

시스템이 명시적입니다.

개발자는 React에게 그들이 원하는 정확한 동작을 말할 수 있습니다.

핵심 변경 사항

개발자는 개체를 사용하도록 선택하거나 현재 시스템을 계속 사용할 수 있습니다.

반응에 관용적

이 변경은 새로운 JSX 구문을 필요로 하지 않으며 React의 다른 API처럼 느껴집니다. 예를 들어, PropTypes(자체 패키지로 이동되더라도)는 다소 유사한 접근 방식을 사용합니다.

단점

복잡한 구성 요소의 경우 많은 작업이 필요할 수 있습니다.

Polymer의 paper-input 요소에는 37개의 속성이 있으므로 매우 큰 구성을 생성합니다. 개발자가 앱에서 많은 사용자 지정 요소를 사용하는 경우 작성해야 하는 구성이 많을 수 있습니다.

번들 크기가 커질 수 있음

위의 요점과 관련하여 각 사용자 정의 요소 클래스는 이제 정의 비용 + 구성 개체 크기를 발생시킵니다.

참고: 이것이 사실인지 100% 확신할 수 없습니다.

구성은 구성 요소와 보조를 맞춰야 합니다.

구성 요소가 새 속성을 추가하는 마이너 버전 개정을 수행할 때마다 구성도 업데이트해야 합니다. 어렵지는 않지만 유지 관리가 추가됩니다. 소스에서 구성을 생성하는 경우 부담이 덜할 수 있지만 이는 각 웹 구성 요소 라이브러리에 대한 구성을 생성하기 위해 새 도구를 생성해야 함을 의미할 수 있습니다.

cc @sebmarkbage @gaearon @developit @treshugart @justinfagnani

DOM Discussion

출처

robdodson

👍178 ❤73 🎉18 🚀10 👀4

가장 유용한 댓글

여러분, 기다리는 동안 React https://www.npmjs.com/package/reactify-wc 에서 웹 구성 요소를 래핑하기 위한 shim을 만들었습니다.

import React from "react";
import reactifyWc from "reactify-wc";

// Import your web component. This one defines a tag called 'vaadin-button'
import "@vaadin/vaadin-button";

const onClick = () => console.log('hello world');

const VaadinButton = reactifyWc("vaadin-button");

export const MyReactComponent = () => (
  <>
    <h1>Hello world</h1>
    <VaadinButton onClick={onClick}>
      Click me!
    </VaadinButton>
  </>
)

이것이 도움이 되기를 바랍니다.

(이것은 내가 OSS에 처음으로 진출한 것이고, 사무실 밖에서 무언가를 공개한 최초의 것 중 하나입니다. 건설적인 비판은 더할 나위 없이 환영입니다 😄 )

BBKolton 에 2019년 10월 02일

👍27 ❤5 🎉4

모든 129 댓글

긴 글을 읽어서 죄송하지만 각 옵션을 철저히 조사하고 있는지 확인하고 싶었습니다. 제 의견으로 너무 편향되고 싶지는 않지만, 만약 제가 선택의 여지가 있다면 3번을 택할 것 같아요.

옵션 3은 이전 버전과 호환되고 선언적이며 명시적입니다. 대체 휴리스틱을 유지할 필요가 없으며 다른 라이브러리는 이미 유사한 기호/수정자를 제공합니다.

robdodson 에 2017년 10월 24일

👍6

긴 글을 읽어서 죄송하지만 각 옵션을 철저히 조사하고 있는지 확인하고 싶었습니다. 제 의견으로 너무 편향되고 싶지는 않지만, 만약 제가 선택의 여지가 있다면 3번을 택할 것 같아요.
옵션 3은 이전 버전과 호환되고 선언적이며 명시적입니다. 대체 휴리스틱을 유지할 필요가 없으며 다른 라이브러리는 이미 유사한 기호/수정자를 제공합니다.

worawit15379 에 2017년 10월 24일

저는 옵션 2와 옵션 3 사이에 있습니다. React는 과거에 동작과 API 변경 사항을 매우 잘 처리했다고 생각합니다. 경고 및 문서 링크를 도입하면 개발자가 내부에서 일어나는 일을 이해하는 데 도움이 될 수 있습니다.

옵션 3은 선언적 특성으로 인해 매력적으로 보이지만 JSX 코드를 읽는 동안 새로 오는 개발자는 요소를 렌더링할 때 React가 수행하는 작업을 즉시 알 수 있습니다.

jeremenichelli 에 2017년 10월 24일

옵션 2에 대한 의견

개발자는 React가 요소를 로드하기 위해 선택한 방법에 따라 속성 대신 속성을 설정할 때 혼란스러울 수 있습니다.

사용자 정의 요소의 소비자는 이 구분을 이해할 필요가 있습니까? 아니면 커스텀 요소의 작성자에게만 중요한가요? DOM에서 복잡한 값이나 속성 가져오기/설정을 지원하려면 요소 작성자가 HTML(HTML 사용에서 데이터가 전달되는 유일한 방법이기 때문에) 및 속성에 사용되는 모든 속성을 처리해야 할 것 같습니다. 작성자가 처음에 속성으로 구현한 다음 나중에 동일한 이름의 속성을 추가하여 보다 유연한 데이터 유형을 지원하고 속성에 저장된 값으로 속성을 백업할 수도 있습니다.

미래의 HTMLElement 속성 및 속성과의 이름 충돌은 바인딩 접근 방식에 관계없이 오류를 유발할 수 있기 때문에 일반적으로 웹 구성 요소 표준의 약점으로 보입니다.

요소에 정의되지 않은 속성이 있고 React가 개체/배열을 전달하려고 하면 속성으로 설정됩니다. 이것은 some-attr="[object Object]"가 유용하지 않기 때문입니다.

값에 따라 다르게 바인딩하는 것은 혼란스러울 것 같습니다. 요소 작성자가 값을 처리하기 위해 속성 getter/setter를 지정하지 않은 경우 속성을 설정하면 요소가 값이 지정되지 않은 것처럼 작동하여 디버그하기 더 어려울 수 있습니다.

옵션 3에 대한 의견

옵션 3의 또 다른 잠재적인 단점은 사용자 지정 요소의 소비자가 요소가 속성 또는 속성으로 구현했는지 여부를 알아야 한다는 것입니다. React 구성 요소와 사용자 정의 요소를 혼합하여 사용하는 경우 하나의 구문을 사용하여 React 소품을 설정하고 다른 구문을 사용하여 사용자 정의 요소 속성을 설정하는 것이 혼란스러울 수 있습니다.

cjorasch 에 2017년 10월 24일

사용자 정의 요소의 소비자는 이 구분을 이해할 필요가 있습니까? 아니면 커스텀 요소의 작성자에게만 중요한가요?

당신이 지적했듯이 요소 작성자가 기본 값에 대한 속성과 속성을 정의하고 둘 다의 데이터를 수락해야 하기 때문에 이것이 실제로 큰 문제인지 의심스럽습니다. 또한 속성과 속성을 동기화 상태로 유지해야 한다고 덧붙였습니다(하나를 설정하면 다른 하나가 설정됨).

미래의 HTMLElement 속성 및 속성과의 이름 충돌은 바인딩 접근 방식에 관계없이 오류를 유발할 수 있기 때문에 일반적으로 웹 구성 요소 표준의 약점으로 보입니다.

동의하지만 이것이 React가 라이브러리에서 해결해야 할 사항인지 확실하지 않습니다. 커스텀 요소 사양의 일부로 해결해야 할 문제처럼 느껴집니다. 다가오는 TPAC 표준 회의의 일부로 이에 대해 논의할 수 있는지 알 수 있습니다.

요소 정의 속성이 HTMLElement에 추가되는 미래 속성을 가리기 때문에 속성의 경우 이것은 나쁘지 않습니다. 따라서 js 속성으로 사용자 정의 요소에 데이터를 전달하는 경우 계속 작동합니다. 주요 문제는 속성이 전역적이기 때문에 속성과 관련된 것 같습니다.

값에 따라 다르게 바인딩하는 것은 혼란스러울 것 같습니다. 요소 작성자가 값을 처리하기 위해 속성 getter/setter를 지정하지 않은 경우 속성을 설정하면 요소가 값이 지정되지 않은 것처럼 작동하여 디버그하기 더 어려울 수 있습니다.

사용자 정의 요소가 지연 로드되고 "업그레이드"된 경우 처음에는 정의되지 않은 속성이 있습니다. 이는 해당 요소가 여전히 데이터를 수신하고 업그레이드 후에도 사용할 수 있도록 하여 해당 사용 사례를 해결합니다.

작성자가 값에 대한 getter/setter를 정의하지 않으면 이것은 매우 유용하지 않을 것입니다. 그러나 my-attr=[object Object] 가 있는 것도 유용하지 않습니다. 그리고 속성이 정말로 정의되지 않은 것인지 아니면 정의가 지연 로드되는지 알 수 없으므로 속성을 설정하는 것이 가장 안전해 보입니다.

옵션 3의 또 다른 잠재적인 단점은 사용자 지정 요소의 소비자가 요소가 속성 또는 속성으로 구현했는지 여부를 알아야 한다는 것입니다.

사용자 정의 요소 작성자가 속성 대신 속성을 정의하도록 강제하는 것이 없기 때문에 귀하는 오늘날 본질적으로 같은 배에 있다고 생각합니다. 따라서 React의 현재 시스템에서 데이터를 수신하지 않는 속성 전용 API가 있는 요소를 가질 수 있으며 ref 를 사용하여 js 속성을 직접 설정하는 방법을 알아야 합니다.

사용자 정의 요소는 기본 요소이므로 해당 속성 및 속성을 강제로 생성하는 것은 없습니다. 그러나 우리는 그렇게 하는 것을 모범 사례로 장려하기 위해 매우 열심히 노력하고 있으며, 오늘날 내가 알고 있는 모든 라이브러리는 해당 속성에 대한 지원 속성을 생성합니다.

[편집하다]

이전 요점에서 언급했듯이:

DOM에서 복잡한 값이나 속성 가져오기/설정을 지원하려면 요소 작성자가 HTML(HTML 사용에서 데이터가 전달되는 유일한 방법이기 때문에) 및 속성에 사용되는 모든 속성을 처리해야 할 것 같습니다.

사용자가 요소에 데이터를 전달하는 방법을 알 수 없기 때문에 결국 속성-속성 대응이 필요하게 됩니다. 옵션 3이 제공되면 대부분의 사람들이 @ 사용하여 모든 것을 묶을 것입니다. 왜냐하면 그것이 가장 쉽기 때문입니다. 그것이 .prop 수식어를 노출하기 때문에 오늘날 Vue에서 사용자 정의 요소로 작업하는 방법입니다.

robdodson 에 2017년 10월 24일

사용자 정의 요소의 소비자는 요소가 속성 또는 속성으로 구현했는지 여부를 알아야 합니다.

내 생각에는 Rob이 말했듯이 React가 걱정해야 할 부분이 아닙니다. 사용자에게 요소가 작동하는 방식을 알려주는 것은 사용자 정의 요소 작성자의 책임입니다.

그리고 이것은 실제로 오늘날 우리가 해야 하는 방식입니다. 예를 들어 <video> 요소에 대해 생각해 보십시오. 이를 음소거하거나 구성 요소 내부의 현재 시간을 변경해야 한다고 가정해 보겠습니다.

muted 는 부울 속성으로 작동합니다.

render() {
  return (
    <div className="video--wrapper">
      <video muted={ this.state.muted } />
    </div>
  );
}

현재로서는 video 요소를 가리키는 ref 를 만들고 속성을 변경해야 합니다.

render() {
  return (
    <div className="video--wrapper">
      <video ref={ el => this.video = el } muted={ this.state.muted } />
    </div>
  );
}

그런 다음 인스턴스 메서드인 이벤트 핸들러를 만들고 속성을 DOM 요소로 수동으로 설정합니다.

onCurrenTimeChange(e) {
  this.video.currentTime = e.value;
}

currentTime 가 래퍼 구성 요소의 상태임이 분명하기 때문에 React 자체가 API 및 JSX 추상 레이어로 부과하는 선언적 모델을 깨뜨립니다. 속성 바인딩을 사용하면 여전히 이벤트 핸들러가 필요하지만 JSX 추상화 모델은 더 선언적이며 refs는 다음과 같은 경우에만 필요하지 않습니다.

render() {
  return (
    <div className="video--wrapper">
      <video muted={ this.state.muted } @currentTime={ this.state.currentTime } />
    </div>
  );
}

내 요점은 네이티브 또는 사용자 정의 요소에 의존하는지 여부에 관계없이 문서를 기반으로 해당 요소를 우회하는 방법을 알아야 한다는 것입니다. 두 번째 경우에는 사용자 정의 요소의 작성자가 제공해야 한다는 차이점이 있습니다.

@cjorasch 내 두 센트 :)

jeremenichelli 에 2017년 10월 24일

이전 버전과의 호환성을 고려할 필요 없이 처음부터 이것을 설계했다면 React의 "JavaScript-centric API to DOM"에 따라 옵션 1이 가장 관용적일 것이라고 생각합니다.

서버 측 렌더링과 관련하여 사용자 정의 요소 속성을 속성에 매핑하는 방법을 React에 알리는 애플리케이션 코드용 API를 제공하여 해당 문제를 해결할 수 있습니까? 플랫폼 정의 속성에 대해 React가 이미 유지 관리하는 맵과 유사합니까? 이 API는 사용자 정의 요소 이름당 한 번만 호출하면 되며(각 인스턴스에 대해가 아님) 속성과의 직접적인 1:1 대응을 따르지 않는 속성에 대해서만 호출해야 합니다.

우리가 이것이 너무 많은 주요 변경 사항이라고 우려한다면 옵션 3도 꽤 매력적이라고 생각합니다. sigil이 속성을 의미하는 경우 "."를 제안합니다. 이미 JavaScript의 속성 접근자이기 때문입니다. 그러나 애플리케이션에서 사용자 정의 요소가 사용되는 모든 인스턴스가 속성을 사용할 때와 속성을 사용할 때를 아는 책임을 지게 하는 것은 불행한 일이라고 생각합니다. 옵션 1에 대해 내가 선호하는 것은 속성 맵에 대한 속성이 필요하더라도 해당 매핑 코드를 모든 JSX 사용에서 격리할 수 있다는 것입니다.

effulgentsia 에 2017년 10월 24일

사용자 정의 요소가 지연 로드되고 "업그레이드"된 경우 처음에는 정의되지 않은 속성이 있습니다. 이는 해당 요소가 여전히 데이터를 수신하고 업그레이드 후에도 사용할 수 있도록 하여 해당 사용 사례를 해결합니다.

업그레이드 과정을 이해하지 못하는 것일 수도 있습니다. 요소는 일반적으로 클래스 프로토타입에서 getter/setter로 정의된 속성을 갖습니다. propName in element 확인하면 속성 값이 아직 정의되지 않은 경우에도 getter/setter가 있기 때문에 true를 반환합니다. 업그레이드하는 동안 속성 값이 일부 임시 인스턴스에 설정되고 나중에 지연 로드가 완료되면 실제 인스턴스에 복사됩니까?

cjorasch 에 2017년 10월 24일

업그레이드는 사용자 정의 요소가 해당 클래스를 수신하는 프로세스입니다. 그 전에는 해당 클래스의 인스턴스가 아니므로 속성 getter/setters를 사용할 수 없습니다.

effulgentsia 에 2017년 10월 24일

@jeremenichelli

음소거는 부울 속성으로 작동합니다.

방금 확인했으며 MDN에 문서화되어 있지 않은 것 같지만 해당 속성도 있습니다.

현재로서는 비디오 요소를 가리키는 참조를 만들고 속성을 변경해야 합니다.

예, 때때로 현대 HTML 요소에서 속성 전용 API를 접하게 됩니다. currentTime 는 높은 빈도로 업데이트되므로 HTML 속성에 반영하는 것은 의미가 없습니다.

내 요점은 기본 요소 또는 사용자 정의 요소에 의존하든 문서를 기반으로 하는 방법을 여전히 알아야 한다는 것입니다.

네, 불행히도 만능 속성/속성 규칙은 없습니다. 그러나 일반적으로 속성에 크게 의존하고 개발자가 특수한 경우에 속성을 사용할 수 있도록 구문을 제공할 수 있다고 생각합니다.

robdodson 에 2017년 10월 24일

👍1

@robdodson yeap, 나도 음소거된 속성에 대해 알고 있었습니다 😄 방금 이 두 가지를 사용하여 이미 _야생에서_ 당신이 언급한 것과 같이 획일적인 규칙이 없다는 것을 증명했습니다.

우리는 기본 요소와 사용자 정의 요소 모두에 대한 문서에 의존해야 하므로 이 결정에 대해 신경 쓰지 않을 것입니다.

마지막 코드 스니펫을 작성하는 동안 속성 바인딩이 마음에 들었습니다. 💟

jeremenichelli 에 2017년 10월 24일

👍1

@effulgentsia

그러나 애플리케이션에서 사용자 정의 요소가 사용되는 모든 인스턴스가 속성을 사용할 때와 속성을 사용할 때를 아는 책임을 지게 하는 것은 불행한 일이라고 생각합니다.

나는 이것이 오늘날에도 이미 그러하다고 생각한다. 주요 사용자 정의 요소 라이브러리(폴리머, 스케이트, 아마도 기타?)는 노출된 모든 속성에 대한 지원 속성을 자동으로 생성하므로 개발자는 사용자 정의 요소의 모든 속성에 대해 sigil을 사용할 수 있습니다. 속성 사용으로 전환해야 하는 경우는 드물 것입니다.

@cjorasch

RE: 업그레이드. @effulgentsia가 언급했듯이 페이지에 사용자 정의 요소를 가질 수 있지만 나중에 해당 정의를 로드할 수 있습니다. <x-foo> 는 처음에 HTMLElement 의 인스턴스가 되고 나중에 정의를 로드하면 "업그레이드"되어 XFoo 클래스의 인스턴스가 됩니다. 이 시점에서 모든 수명 주기 콜백이 실행됩니다. 폴리머 스타터 키트 프로젝트에서 이 기술을 사용합니다. 다음과 같은 종류:

<app-router>
  <my-view1></my-view1>
  <my-view2></my-view2>
</app-router>

위의 예에서 라우터가 변경될 때까지 my-view2 대한 정의를 로드하지 않습니다.

요소가 업그레이드되기 전에 요소에 속성을 설정하는 것은 전적으로 가능하며, 정의가 로드되면 요소는 수명 주기 콜백 중 하나에서 해당 데이터를 가져올 수 있습니다.

robdodson 에 2017년 10월 24일

개발자는 사용자 정의 요소의 모든 속성에 대해 sigil을 사용할 수 있습니다.

개발자가 그렇게 하기 시작했다면 "할 수 있기" 때문에 속성을 사용하는 것과 "반드시" 해야 하기 때문에 속성을 사용하는 것을 어떻게 구별할까요? 그리고 그것이 서버 측 렌더링에 필요한 차별화가 아닐까요?

effulgentsia 에 2017년 10월 24일

개발자가 그렇게 하기 시작했다면 "할 수 있기" 때문에 속성을 사용하는 것과 "반드시" 해야 하기 때문에 속성을 사용하는 것을 어떻게 구별할까요?

죄송합니다. 제가 표현을 잘못했을 수도 있습니다. 나는 그것이 가장 일관된 결과를 줄 것이기 때문에 개발자들이 sigil을 사용할 가능성이 있다는 것을 의미했습니다. 개체 및 배열과 같은 기본 데이터 또는 풍부한 데이터를 전달하는 데 사용할 수 있으며 항상 작동합니다. 속성은 초기 구성에 더 많이 사용되는 경향이 있기 때문에 런타임에 속성으로 작업하는 것이 일반적으로 속성으로 작업하는 것보다 선호된다고 생각합니다.

그리고 그것이 서버 측 렌더링에 필요한 차별화가 아닐까요?

서버에서 sigil이 속성을 설정하는 것으로 대체되는 경우일 수 있습니다.

robdodson 에 2017년 10월 24일

서버에서 sigil이 속성을 설정하는 것으로 대체되는 경우일 수 있습니다.

sigil의 이유가 비디오의 currentTime 과 같은 속성으로 존재하지 않는 속성인 경우 작동하지 않을 것이라고 생각합니다.

"할 수 있기 때문에" 속성을 사용하는 것과 "해야"하기 때문에 속성을 사용하는 것을 구별합니다.

속성이나 속성을 최적화로 사용하기로 선택하는 이유(예: 속성을 선호하는 SSR 대 속성을 선호하는 클라이언트 측 렌더링)와 속성으로만 존재하거나 속성으로만 존재하는 것에는 완전히 다른 이유가 있기 때문에 이 차별화가 중요하다고 생각합니다. 재산.

서버 측 렌더링과 관련하여 사용자 정의 요소 속성을 속성에 매핑하는 방법을 React에 알리는 애플리케이션 코드용 API를 제공하여 해당 문제를 해결할 수 있습니까?

더 구체적으로 말하면 다음과 같이 제안합니다.

ReactDOM.defineCustomElementProp(elementName, propName, domPropertyName, htmlAttributeName, attributeSerializer)

예:

// 'muted' can be set as either a property or an attribute.
ReactDOM.defineCustomElementProp('x-foo', 'muted', 'muted', 'muted')

// 'currentTime' can only be set as a property.
ReactDOM.defineCustomElementProp('x-foo', 'currentTime', 'currentTime', null)

// 'my-attribute' can only be set as an attribute.
ReactDOM.defineCustomElementProp('x-foo', 'my-attribute', null, 'my-attribute')

// 'richData' can be set as either a property or an attribute.
// When setting as an attribute, set it as a JSON string rather than "[object Object]".
ReactDOM.defineCustomElementProp('x-foo', 'richData', 'richData', 'richdata', JSON.stringify)

속성( htmlAttributeName 이 null인 경우)일 수 있는 항목의 경우 SSR은 렌더링을 건너뛰고 클라이언트에서 수화합니다.

속성( domPropertyName 이 null인 경우)일 수 있는 항목의 경우 React는 현재 v16에서와 같이 setAttribute() 를 호출합니다.

둘 다일 수 있는 경우 React는 가장 최적의 전략을 선택할 수 있습니다. 아마도 그것은 항상 클라이언트 측에서 속성으로 설정하지만 서버 측 속성으로 설정하는 것을 의미합니다. 아마도 처음에는 요소를 생성할 때 속성으로 설정하지만 나중에 vdom에서 패치할 때 속성으로 설정하는 것을 의미합니다. 아마도 값이 원시 유형일 때 속성으로만 설정한다는 의미일 것입니다. 이상적으로 React는 내부 구현 세부 사항으로 원할 때마다 전략을 변경할 수 있어야 합니다.

React가 defineCustomElementProp() 가 호출되지 않고 HTML 사양에 전역 속성 또는 속성으로 정의되지 않은 prop을 발견하면 React는 일부 기본 논리를 구현할 수 있습니다. 예를 들어, 아마도:

버전 17에서는 v16으로 BC를 유지하고 속성으로 설정합니다.
버전 18에서는 둘 중 하나일 수 있다고 가정하고 이에 대한 가장 최적의 전략을 따르십시오.

그러나 어쨌든 이것을 별도의 API로 유지함으로써 JSX 및 props 객체는 React 구성 요소 및 사용자 정의가 아닌 HTML 요소와 마찬가지로 단일 네임스페이스 내에서 깨끗하게 유지됩니다.

effulgentsia 에 2017년 10월 24일

과도한 의견에 대해 유감스럽게 생각하지만 위의 제안에 대해 공유하고 싶은 또 다른 이점이 있습니다.

이러한 ReactDOM.defineCustomElementProp() 호출은 사용자 정의 요소 작성자가 유지 관리하는 JS 파일에서 제공될 수 있습니다(사용자 정의 요소가 유지/배포되는 위치와 동일한 저장소). 속성/속성이 엄격하게 1:1로 일치하는 사용자 지정 요소에는 필요하지 않습니다. 따라서 이 권장 사항을 따르지 않는 사용자 지정 요소 작성자만 React 통합 파일을 제공해야 합니다. 작성자가 제공하지 않는 경우(예: 사용자 정의 요소 작성자가 React에 관심이 없기 때문에) React 앱 내에서 해당 사용자 정의 요소를 사용하는 사람들의 커뮤니티는 해당 통합 파일을 수용하기 위해 중앙 저장소를 자체 구성할 수 있습니다.

이러한 중앙 집중화의 가능성은 사용자 정의 요소의 모든 사용자가 항상 sigil을 사용하여 명시적이어야 하는 솔루션보다 바람직하다고 생각합니다.

effulgentsia 에 2017년 10월 25일

옵션 3이 선호되지만 이는 엄청난 변화입니다... 반대의 경우는 어떻습니까? 속성에 props가 아닌 접두사가 있습니까?

LeeCheneler 에 2017년 10월 25일

React의 Sigils, 나는 그것에 대해 어떻게 느끼는지 모릅니다. JSX 사양은 브라우저 사양에 지나치게 의존하거나 의존하지 않는 보편적인 것으로 간주되어야 합니다. 특히 이전 버전과의 호환성으로 인한 불규칙성에 대해서는 더 그렇습니다. obj[prop] = value 와 obj.setAttributes(props, value) 다르게 동작하는 것은 불행한 일이지만 브라우저 API를 전체적으로 보면 놀라운 일이 아닙니다. @ : [] 는 구현 세부 사항을 표면으로 유출하고 자바스크립트 중심 접근 방식과 모순됩니다. 따라서 다음을 수행하는 사양이 없으면 잘못된 생각이라고 생각합니다. const data = <strong i="8">@myFunction</strong> // -> "[object Object]"

웹 구성 요소에 의존해야 하는 경우 의미 체계가 React 및 JSX에서 숨겨지고 주요 변경 사항이 도입되지 않도록 하면 기쁠 것입니다. 모든 옵션에서 ref => ... 를 그대로 두는 것이 나에게 유리한 것 같습니다. ref 는 개체에 액세스하도록 특별히 설계되었습니다. 그리고 적어도 개발자는 무슨 일이 일어나고 있는지 정확히 알고 있고, 인장 누출도 없고 기존 프로젝트를 깨뜨릴 수 있는 새로운 속성도 없습니다.

drcmda 에 2017년 10월 25일

👍1

@LeeCheneler

옵션 3이 선호되지만 이는 엄청난 변화입니다... 반대의 경우는 어떻습니까? 속성에 props가 아닌 접두사가 있습니까?

왜 획기적인 변화가 될까요? 기본값인 속성의 현재 동작은 그대로 유지됩니다. sigil은 옵트인이며 개발자는 현재 ref 를 사용하여 사용자 정의 요소에 JS 속성으로 데이터를 전달하는 코드의 부분을 대체하는 데 사용할 것입니다.

@drcmda

기존 프로젝트를 중단시킬 수 있는 새로운 속성도 없습니다.

이것이 무엇을 의미했는지 명확히 할 수 있습니까?

robdodson 에 2017년 10월 25일

참고로 토론을 따르는 사람을 위해 React 팀 구성원이 제안한 다섯 번째 옵션으로 RFC를 업데이트했습니다.

robdodson 에 2017년 10월 25일

@robdodson

나는 이것을 언급하고 있었다:

옵션 4: 속성 개체 추가
단점
획기적인 변화일 수 있습니다

drcmda 에 2017년 10월 25일

옵션 5가 가장 안전한 것 같습니다. 생태계가 아직 "파악" 단계에 있기 때문에 "암시적" API에 대한 결정을 내릴 필요 없이 기능을 추가할 수 있습니다. 우리는 항상 몇 년 안에 그것을 다시 방문할 수 있습니다.

Polymer의 paper-input 요소에는 37개의 속성이 있으므로 매우 큰 구성을 생성합니다. 개발자가 앱에서 많은 사용자 지정 요소를 사용하는 경우 작성해야 하는 구성이 많을 수 있습니다.

내 인상은 React의 사용자 정의 요소 사용자가 결국 앱별 동작/사용자 정의를 위해 일부 사용자 정의 요소를 React 구성 요소로 래핑하기를 원한다는 것입니다. 모두가 이미 켜져있는 경우는이 경우에 더 좋은 마이그레이션 전략 구성 요소, 예를 들면 반작용

import XButton from './XButton';

에 의해 생성됩니다.

export default ReactDOM.createCustomElementType(...)

이를 통해 React 구성 요소를 특정 시점에 사용자 정의 요소를 사용하는(또는 사용하지 않는) 사용자 정의 구성 요소로 교체할 수 있습니다.

따라서 사람들이 상호 운용성 지점에서 React 구성 요소를 만들려는 경우 강력한 도우미를 제공하는 것이 좋습니다. 또한 사람들이 사용하는 사용자 지정 요소에 대한 구성을 공유할 가능성도 있습니다.

그리고 궁극적으로 생태계가 안정화되면 구성 없는 접근 방식을 채택할 수 있습니다.

여기에서 다음 단계는 모든 일반적인 사용 사례를 충족하기 위해 구성이 어떻게 보여야 하는지에 대한 자세한 제안을 작성하는 것이라고 생각합니다. 사용자 정의 요소 + React 사용자에게 충분히 매력적이어야 합니다. 왜냐하면 그것이 일반적인 사용 사례(예: 이벤트 처리)에 응답하지 않으면 기능이 장황함을 상쇄할 충분한 이점을 제공하지 못하는 림보에 빠지게 될 것이기 때문입니다. .

gaearon 에 2017년 10월 25일

👍4 👀1

내 이전 의견을 바탕으로 작성하는 방법은 다음과 같습니다.

const XFoo = ReactDOM.createCustomElementType('x-foo', {
  propName1: {
    propertyName: string | null,
    attributeName: string | null,
    attributeSerializer: function | null,
    eventName: string | null,
  }
  propName2: {
  }
  ...
});

그러면 논리는 XFoo 인스턴스의 각 React 소품에 대해 다음과 같습니다.

해당 prop에 대한 eventName 가 null이 아닌 경우 prop 값(함수로 가정)을 호출하는 이벤트 핸들러로 등록합니다.
그렇지 않으면 클라이언트 측 렌더링 및 propertyName 가 null이 아닌 경우 요소 속성을 prop 값으로 설정합니다.
그렇지 않고 attributeName 가 null이 아닌 경우 요소 속성을 문자열화된 prop 값으로 설정합니다. attributeSerializer 가 null이 아닌 경우 이를 사용하여 prop 값을 문자열화합니다. 그렇지 않으면 '' + propValue 됩니다.

Polymer의 paper-input 요소에는 37개의 속성이 있으므로 매우 큰 구성을 생성합니다.

구성은 outlier props에만 필요하다고 제안하고 싶습니다. 구성에 포함되지 않은 XFoo 인스턴스의 모든 소품에 대해 기본적으로 다음과 같이 설정합니다.

값이 함수인 경우:

eventName: the prop name,

또 다른:

propertyName: the prop name,
attributeName: camelCaseToDashCase(the prop name),

effulgentsia 에 2017년 10월 25일

👍1

또는 이벤트를 별도의 네임스페이스에 보관하는 것이 합리적일 수 있습니다. 이 경우 마지막 주석에서 eventName 와 관련된 모든 것을 제거하고 대신 이벤트를 다음과 같이 등록합니다.

<XFoo prop1={propValue1} prop2={propValue2} events={event1: functionFoo, event2: functionBar}>
</XFoo>

effulgentsia 에 2017년 10월 25일

@gaearon @effulgentsia 옵션 1과 옵션 5의 조합에 대해 어떻게 생각하시나요?

옵션 1을 사용하면 사용자 지정 요소의 일반 사용자가 풍부한 데이터를 더 쉽게 전달할 수 있습니다. 저는 앱을 만들고 있고 몇 가지 사용자 정의 요소를 사용하려는 시나리오를 상상하고 있습니다. 나는 그들이 어떻게 작동하는지 이미 알고 있고 그것에 대한 구성을 작성하고 싶을 정도로 투자하지 않았습니다.

옵션 5는 앱 전체에서 종이 입력과 같은 것을 사용하고 전체 API를 팀의 모든 사람에게 공개하려는 사람들을 위한 것입니다.

robdodson 에 2017년 10월 25일

옵션 1의 SSR의 경우 발견적 방법은 서버에서 렌더링하는 경우 항상 속성을 사용할 수 있습니다. camelCase 속성은 dash-case 속성으로 변환됩니다. 이는 웹 구성 요소 라이브러리 전반에 걸쳐 꽤 일반적인 패턴인 것 같습니다.

robdodson 에 2017년 10월 25일

나는 option1 + option5 조합의 아이디어를 아주 좋아합니다. 대부분의 사용자 정의 요소에 대해 다음을 의미합니다.

<x-foo prop1={propValue1}>

예상대로 작동합니다. prop1은 속성 클라이언트 측 및 (대시 대소문자) 서버 측 속성으로 설정됩니다.

그리고 사람들은 위의 내용이 자신에게 적합하지 않은 경우 옵션 5로 전환할 수 있습니다.

React 16이 작동하는 방식에서 획기적인 변화가 될 것입니다. 이러한 파손을 경험한 사람은(예: 속성이 지원되지 않는 속성을 가진 사용자 정의 요소를 사용하고 있는 경우) 옵션 5로 전환할 수 있지만 여전히 중단입니다. 나는 그것이 수용 가능한지 결정하기 위해 React 팀에 맡깁니다.

effulgentsia 에 2017년 10월 25일

👍3

아, 기차 @robdodson 🤦‍♂️ 에서 빨리 읽어서

옵션 5는 합리적이고 간단해 보입니다.

@effulgentsia 가 향하고 있는 듭니다 . 할 수 없는 이유가 있습니까?

const XFoo = ReactDOM.createCustomElementType('x-foo', {
  propName1: T.Attribute,
  propName2: T.Event,
  propName3: T.Prop
})

아니면 단일 소품에서 여러 유형을 지원하는 것이 가치가 있습니까?

나는 @effulgentsia를 통해 이 흐름을 주저할 것입니다.

값이 함수인 경우:
eventName: 소품 이름,
또 다른:
propertyName: 소품 이름,
attributeName: camelCaseToDashCase(소품 이름),

함수 소품이 이벤트로 기본 설정되는 것을 원하지 않고 propertyName과 attributeName을 모두 할당하는 것이 합리적이라고 생각합니까? 위의 질문을 모방하기 위해 언제 둘 다 지원되기를 원하십니까? 🙂

LeeCheneler 에 2017년 10월 25일

@LeeCheneler :

문제 요약의 옵션 1 찬성에서 인용:

Polymer 또는 Skate와 같은 라이브러리로 생성된 모든 요소는 노출된 속성을 뒷받침하는 속성을 자동으로 생성합니다. 이러한 요소는 모두 위의 접근 방식으로 "정상 작동"해야 합니다. 바닐라 구성 요소를 직접 작성하는 개발자는 속성을 사용하여 속성 을 지원하는 것이 좋습니다. 이는 HTML5 요소( <video> , <audio> 등)가 얼마나 현대적인지(즉, <input> 와 같은 이상한 것이 아님)을 반영하기 때문입니다. 구현되었습니다.

이것이 propertyName과 attributeName을 모두 할당하는 것이 합리적인 이유입니다. 모범 사례를 따르는 요소의 실제 사례를 반영하기 때문입니다. 그리고 React가 이를 인식하게 함으로써 React는 상황에 따라 어떤 것을 사용할지 결정할 수 있습니다. 모범 사례를 따르지 않고 해당 속성이 없는 일부 속성 및/또는 해당 속성이 없는 일부 속성이 있는 사용자 지정 요소의 경우 React는 이를 인식해야 SSR 및 속성 중에 속성이 없는 속성이 렌더링되지 않습니다. -less-attributes는 클라이언트 측 렌더링 중에 setAttribute()를 사용하여 설정할 수 있습니다.

귀하의 제안으로 다음과 같은 비트 결합 플래그로 잠재적으로 수행할 수 있습니다.

propName1: T.Property | T.Attribute,

그러나 이는 속성 이름이 속성 이름과 다르다는 것을 표현하는 방법을 제공하지 않습니다(예: camelCase에서 dash-case로). 또한 SSR 동안 리치 개체를 속성으로 직렬화하는 방법을 표현하는 방법도 제공하지 않습니다("[object Object]"의 현재 동작은 유용하지 않음).

함수 소품이 이벤트로 기본 설정되는 것을 원하지 않는다고 생각합니다.

네, 저도 그 말에 동의하는 것 같으니, 후속 댓글 입니다. 내 주저를 확인 주셔서 감사합니다!

effulgentsia 에 2017년 10월 25일

👍1

이전 제안 의 덜 장황한 버전에 대한 생각은 다음과 같습니다.

const XFoo = ReactDOM.createCustomElementType('x-foo', {
  UNREFLECTED_ATTRIBUTES: [
    'my-attr-1',
    'my-attr-2',
  ],
  UNREFLECTED_PROPERTIES: [
    'myProp1',
    'myProp2',
  ],
  REFLECTED_PROPERTIES: {
    // This is default casing conversion, so could be omitted.
    someVeryLongName1: 'some-very-long-name-1',

    // In case anyone is still using all lowercase without dashes.
    someVeryLongName2: 'someverylongname2',

    // When needing to define a function for serializing a property to an attribute.
    someRichData: ['some-rich-data', JSON.stringify],
  },
});

그리고 위의 코드 주석에 따라 모든 반영된 속성을 정의할 필요가 없으며 속성 이름이 대시 대소문자 버전인 반영된 속성으로 자동으로 정의되지 않은 모든 속성을 기본값으로 지정합니다.

effulgentsia 에 2017년 10월 25일

이해가 되네요 @effulgentsia 👍

나는 당신의 두 번째 예를 좋아하지만 더 많은 유형이 추가되면 조합 폭발에 열려 있지 않습니까?

- UNREFLECTED_ATTRIBUTES
- UNREFLECTED_PROPERTIES
- UNREFLECTED_EVENTS
- REFLECTED_PROPERTIES_ATTRIBUTES
- REFLECTED_PROPERTIES_EVENTS
- REFLECTED_ATTRIBUTES_EVENTS
- REFLECTED_PROPERTIES_ATTRIBUTES_EVENTS
...

어쨌든 이벤트를 소품이나 속성과 혼합하고 싶지 않다고 생각하지만 🤔 속성과 소품은 아마도 모방하고 싶은 유일한 것입니다.

LeeCheneler 에 2017년 10월 26일

React와 Web Component 커뮤니티 모두가 모범 사례에 부합할 수 있는 기회가 있다고 생각합니다. React가 여기에서 의견을 갖는 것은 광범위한 채택과 의견이 수반하는 무게로 인해 사용자 정의 요소 작성자가 올바른 방향으로 안내되는 데 큰 도움이 될 것입니다.

옵션 4의 구현을 작성했지만 속성과 이벤트를 속성에서 분리해야 하는 문제에 항상 사로잡혀 있습니다. 이상적으로는 옵션 1을 선호합니다. 실제로는 탈출구가 있는 옵션 2를 선호합니다.

옵션 1이 이상적이지만 해당 속성(aria / data)이 없는 많은 유형의 속성이 있으므로 이러한 속성에 대한 추가 발견적 방법이 필요하고 요소에 속성이 있어야 하는

옵션 2는 주요 변경 사항이 아니므로 선호됩니다. 인스턴스가 생성되기 전에 사용자 정의 요소 정의가 등록되는(또는 속성이 설정되기 전에 로드되는) 모든 상황에서 작동합니다. 이 옵션에 대한 선행 기술은 Preact(cc @developit)이며 지금까지 잘 작동했습니다. 이 경로를 따라가면 성공적인 React 변형으로 입증되었으며 대부분의 상황에서 작동하는 합리적으로 강력하고 중단되지 않는 구현을 제공합니다. 어쨌든, 그것은 React에 단기적인 솔루션을 제공하는 반면 더 나은 솔루션은 장기적으로 평가됩니다.

이것이 작동하지 않는 상황(상황 s ?)의 경우 - 사용자 정의 요소 정의의 지연 로딩 및 우리가 다루지 않은 다른 모든 것 - Incremental DOM이 수행한 것과 같은 탈출 해치가 구현될 수 있습니다. 이것은 @effulgentsia 가 제안하는 것과 유사하지만 x 사용자 정의 요소 수로 확장하는 것이 좋습니다. 소비자가 사용자 정의 요소별로 이를 수행하기를 원하면 여전히 할 수 있습니다. 왜냐하면 그것은 단지 기능이기 때문입니다. 이를 통해 React는 모든 엣지 케이스에 대한 책임을 소비자에게 넘김으로써 의견을 갖고 해치를 벗어나 모든 사용 케이스를 만족시킬 수 있습니다. 이는 이전에 @developit 과 논의한 내용이기도 합니다. 여기서 Preact / React 간의 정렬은 큰 승리가 될 것입니다.

미래의 HTML 속성에 대한 우려에 대해 이것은 우리가 해결할 수 없는 것이므로 여기서 우리가 그것에 대해 고민해야 한다고 생각하지 않습니다.

treshugart 에 2017년 10월 26일

👍3

이러한 ReactDOM.defineCustomElementProp() 호출은 사용자 정의 요소 작성자가 유지 관리하는 JS 파일에서 제공될 수 있습니다.

이것은 사용자 정의 요소 구현을 라이브러리별 구현(이 경우 React)에 연결합니다. 제 생각에는 사용자 정의 요소 작성자에게 너무 큰 부담입니다. 게다가 React를 사용하지 않는 저자의 경우 정의를 전달하도록 설득하는 것은 아무도 원하지 않는 정치 토론으로 이어집니다.

사용자가 실제로 사용하는 속성/속성만으로 사용자 정의 요소의 사용자가 이러한 API를 호출하는 것을 정의하는 것은 유지 관리할 코드가 적고 표현력이 뛰어납니다.

TimvdLippe 에 2017년 10월 26일

👍3

라이브러리 작성자가 React를 사용하지 않더라도 해당 웹 구성 요소의 클라이언트가 속성 구성을 한 번 정의한 다음 사용하는 것이 더 나은 UX라고 주장합니다.

속성이 필요한 웹 구성 요소를 처음 사용할 때는 sigil을 추가하는 것만큼 어렵지만(더 장황하지만 더 명시적) 나중에 사용할 때는 이에 대해 생각할 필요가 없기 때문에 더 쉽습니다. 해당 구성 요소의 모든 단일 호출 사이트. 두 경우 모두 새 웹 구성 요소를 채택할 때 속성/속성 차이를 이해해야 하지만 단일 공유 구성을 사용하면 동일한 앱 내에서 해당 구성 요소의 모든 사용자가 그것에 대해 생각할 필요가 없습니다.

더 많은 React 관용구 이름을 만들 수 있도록 해당 구성에서 속성 이름을 다시 매핑하는 것을 잠재적으로 허용할 수 있습니다. 필요한 경우 XFoo를 필요한 멋진 번역 논리를 수행하는 사용자 정의 React 구성 요소로 교체할 수 있기 때문에 보다 정교한 래퍼로의 업그레이드 경로도 더 원활합니다.

기본적으로 사람들이 구성 요소를 사용할 때마다 속성 구성에 대해 생각하지 않는 것이 가능하다면 그 접근 방식을 선호합니다. 그래서 5번 옵션을 제안했습니다. 3번과 4번보다 인체공학적이면서 동시에 유연하다고 생각합니다.

옵션 1과 2는 서버 렌더링(HTML 생성)에서 잘 작동하지 않으며 옵션 2는 또한 웹 구성 요소 작성자에게 업그레이드 위험을 생성합니다. 여기서 기존 속성과 동일한 이름을 가진 속성을 추가하는 것은 주요 변경 사항입니다. SSR이 유용하지 않다고 결정하면 옵션 1이 React 관점에서 꽤 매력적입니다. 실제로 충분히 포괄적인지는 잘 모르겠습니다. 구성 요소 작성자가 속성을 통해 모든 것을 노출합니까?

sophiebits 에 2017년 10월 26일

@treshugart 자전거 세단 에 너무 깊이 들어

robdodson 에 2017년 10월 27일

@sophiebits님이 답글을 이제서야 보게 되어 죄송합니다. 나는 그것을 몇 번 더 읽은 후에 몇 가지 요점에 응답하고 싶지만 이것에 신속하게 응답하고 싶었습니다.

실제로 충분히 포괄적인지는 잘 모르겠습니다. 구성 요소 작성자가 속성을 통해 모든 것을 노출합니까?

Polymer 또는 Skate로 구축된 모든 구성 요소는 속성을 통해 모든 것을 노출합니다. 몇 가지 드문 이상치가 있을 수 있지만(스타일 지정을 위한 속성 설정 등) 그렇지 않으면 항상 속성이 뒷받침한다고 생각합니다. 나는 대부분의 프로덕션 웹 구성 요소가 이 두 라이브러리 중 하나를 사용하여 구축된다고 확신합니다.

누군가가 바닐라 웹 구성 요소를 수동으로 작성하는 경우 속성을 통해 모든 것을 노출하도록 강요하는 것은 없지만 모범 사례 문서 및 예제 에서 그렇게 하도록 권장합니다.

그만한 가치가 있기 때문에 속성을 사용하도록 강요하는 것도 없습니다. 사용자 정의 요소 정의는 개발자가 원하는 모든 작업을 수행할 수 있도록 하는 클래스일 뿐입니다. 그러나 실제로 대부분의 사람들은 구성 요소를 생성하기 위해 Polymer 또는 Skate와 같은 추상화를 사용하는 것을 선호하므로 속성 API를 무료로 받습니다.

robdodson 에 2017년 10월 27일

아마도 가장 좋은 방법은 항상 클라이언트 측에서 속성을 수행한 다음 앱에서 SSR을 지원하려는 사람들을 위해 기본 속성 이름에 대한 옵션 5 스타일 구성 맵을 속성 이름으로 지원하는 것입니다.

sophiebits 에 2017년 10월 27일

👍4

@sophiebits : 속성 이름을 사용하여 React 앱을 작성한 사람들에게 획기적인 변화라는 점을 제외하고는 좋은 아이디어라고 생각합니다. 예를 들어:

<x-foo long-name={val} />

그러나 propname에 대시가 없으면 "do 속성"에 대한 규칙과 대시가 있으면 "do 속성"에 대한 규칙은 어떻습니까?

@robdodson : 대시를 포함하지 않고 해당 속성의 속성 대소문자가 다른 사용자 지정 요소 프레임워크 또는 관행을 알고 있습니까? 즉, longname 속성이 있는 longName 속성? 그것은 실제로 내장 HTML 요소와 전역 속성(예: contenteditable => contentEditable )을 사용하는 훨씬 더 일반적인 패턴인 것 같지만 이제 충분히 권장되지 않는지 확실하지 않습니다. Polymer 및 Skate 덕분에 사용자 정의 요소 속성에 대해. 여전히 문제인 경우 다음이 포함된 기존 JSX:

<x-foo longname={val} />

속성이 longName 이면 속성 집합으로 실패합니다.

effulgentsia 에 2017년 10월 27일

@effulgentsia 저는 Skate에 대해서만 말할 수 있지만 HTML을 작성하는 경우에만 속성 API를 사용하는 것이 좋습니다. 모든 의도와 목적을 위해 서버 렌더링으로도 분류될 수 있습니다. JS를 통해 무엇이든 하고 있다면 props를 설정해야 합니다. 우리의 props API는 속성에서 자동으로 단방향 동기화/역직렬화를 수행하고 속성 이름을 대시로 구분하여 속성 이름을 파생합니다(camelCase는 camel-case 등). 이 동작은 전체적으로 구성할 수 있지만 앞서 언급한 모범 사례를 권장합니다.

많은 사람들이 말했듯이 props는 SSR을 어렵게 만들고 이것은 유효한 우려입니다. 대부분이 옵션 1을 선호하는 것처럼 들리므로 @sophiebits 의 클라이언트에 소품을 설정하는 동시에 폴백/매핑을 제공하는 제안을

예를 위해, 여기 당신이 구현 스케이트와 클라이언트 (및 사용자 정의 요소가 서버로부터 상태 및 소품을 통해 수행 구현할 수있는 방법을 renderedCallback() 및 props 및 / 또는 state setters. 사용자 정의 요소 수준에서 그렇게 하는 것은 간단합니다. React가 서버에서 속성을 설정하는 길을 갔다면, 재수화는 본질적으로 동일할 것입니다. Skate 구성 요소 작성자는 실제로 우리처럼 아무 것도 할 필요가 없습니다. 이미 그들에게 역직렬화 논리를 제공했을 것입니다.

@robdodson 나는 Incremental DOM이 하는 것과 비슷한 일을 할 것입니다. 이것은 다음과 같이 보일 것입니다:

const isBrowser = true; // this would actually do the detection
const oldAttributeHook = ReactDOM.setAttribute;

// This is much like the IDOM impl but with an arguably more clear name.
ReactDOM.setAttribute = (element, name, value) => {
  // This is essentially option 2, but with the added browser check
  // to keep attr sets on the server.
  if (isBrowser && name in element) {
    element[name] = value;
  } else {
    oldAttributeHook(element, name, value);
  }
};

treshugart 에 2017년 10월 27일

@sophiebits

옵션 2는 또한 기존 속성과 이름이 같은 속성을 추가하는 것이 주요 변경 사항인 웹 구성 요소 작성자에게 업그레이드 위험을 만듭니다.

속성이 플랫폼에서 작동하는 방식을 고려할 때 이것이 불가피할 수 있다고 생각합니다. 사용자 지정 요소를 SSR하여 속성에 써야 하는 경우 향후 플랫폼에서 유사한 이름의 속성을 제공할 위험도 있습니다. @treshugart가 이전 에

이것이 옵션 2에 대해 마음이 바뀌었는지 확신할 수 없지만 옵션 2에는 몇 가지 멋진 보너스가 있고 Preact가 실제로 그것을 증명하는 것 같기 때문에 언급하고 싶었습니다.

아마도 가장 좋은 방법은 항상 클라이언트 측에서 속성을 수행한 다음 앱에서 SSR을 지원하려는 사람들을 위해 기본 속성 이름에 대한 옵션 5 스타일 구성 맵을 속성 이름으로 지원하는 것입니다.

+1, 저는 이 방향으로 계속 나아가는 것을 지지합니다.

@effulgentsia

속성 이름을 사용하여 React 앱을 작성한 사람들에게 획기적인 변화라는 점을 제외하고는 훌륭한 아이디어라고 생각합니다.

옵션 2는 그것을 해결할 것입니다 :)
그렇지 않으면 대시 케이스 속성을 camelCased 속성에 매핑하는 옵션 1과 결합된 경험적 방법이 필요할 수 있습니다.

그러나 propname에 대시가 없으면 "do 속성"에 대한 규칙과 대시가 있으면 "do 속성"에 대한 규칙은 어떻습니까?

이름에 대시가 있으면 Preact 가 속성을 설정하는 것처럼 보입니다. 나는 그들이 옵션 2를 사용하고 long-name 가 in 검사를 통과하지 못하여 속성( source )으로 대체되기 때문이라고 가정합니다.

나는 개인적으로 이 동작을 좋아하지만 속성을 설정하는 영역과 미래에 발생할 수 있는 충돌로 돌아가므로 @sophiebits 가 무게를

대시를 포함하지 않고 해당 속성의 속성 대소문자가 다른 사용자 지정 요소 프레임워크 또는 관행을 알고 있습니까?

내가 알기로는 아니야. 대시를 사용하면 도서관에서 낙타 케이스의 위치를 쉽게 알 수 있습니다. 바닐라 웹 구성 요소를 수동으로 작성하는 경우 longname/longName 할 수 있으며 longname 속성을 찾지 못하기 때문에 옵션 2만 저장되지만 이전에 사용된 구성 요소로 대체됩니다. longname 속성.

그만한 가치가 있기 때문에 Preact는 최후의 수단 으로 속성 을 설정하기 전에 <x-foo longName={bar}/> SSR하는 경우 longname="" 속성으로도 적절하게 폴백됩니다.

@treshugart

대체/매핑을 제공하면서 클라이언트에 소품을 설정하자는 @sophiebits 의 제안을

예, 예.

나는 Incremental DOM이 하는 것과 비슷한 일을 할 것입니다.

모든 요소(또는 기본 클래스)가 이것을 혼합해야 한다는 아이디어입니까?

robdodson 에 2017년 10월 27일

btw, 토론에 계속 참여해 주셔서 감사합니다. 꽤 오래되었다는 것을 알고 있습니다 ❤️

robdodson 에 2017년 10월 27일

https://github.com/facebook/react/issues/11347#issuecomment -339858314의 마지막 예를 이해했는지 확실하지 않지만 이와 같은 전역 재정의 가능한 후크를 제공할 가능성은 거의 없습니다.

gaearon 에 2017년 10월 27일

@gaearon 나는 Trey가 원숭이 패치로 순 변경 사항을 보여주고 있다고 생각합니다. 아마도 ReactDOM 구현 자체에 작성되었을 것입니다.

developit 에 2017년 10월 27일

👍1

최근 의견을 바탕으로 이 제안에 대해 어떻게 생각하십니까?

BC의 경우 React에서 소문자 사용자 정의 요소가 작동하는 방식에 대해 아무 것도 변경하지 마십시오. 즉, <x-foo ... /> 와 같은 JSX는 React 16에서와 마찬가지로 React 17에서도 계속 동일한 방식으로 작동합니다. 또는 _사소한_ 버그 수정이 필요한 경우 별도의 문제를 열어 이에 대해 논의하세요.
더 나은 사용자 정의 요소 의미 체계로 React 구성 요소를 생성하기 위해 config-less API를 추가하십시오. 예: const XFoo = ReactDOM.customElement('x-foo'); .
위에서 만든 구성 요소에 대해 다음 의미 체계를 사용합니다.
예약된 React prop 이름( children , ref , 기타?)인 XFoo의 모든 prop에 대해 일반적인 React 의미 체계를 적용합니다(속성이나 속성으로 설정하지 마십시오. 사용자 정의 요소 DOM 노드에서).
HTML 사양에 의해 정의된 HTMLElement 전역 속성 또는 속성 ( data-* 및 aria-* )에 대해 div 에 있는 경우 React에서 수행하는 것과 동일한 작업을 해당 소품으로 수행합니다 <XFoo data-x={} className={} contentEditable={} /> 의 props를 DOM 노드에 적용하는 방법은 <div data-x={} className={} contentEditable={} /> (클라이언트 측 및 SSR 모두)에 적용하는 방법과 동일해야 합니다.
대시를 포함하는 XFoo의 모든 소품(위에서 허용된 전역 속성 제외)에 대해 경고를 내보내고(개발자에게 XFoo가 속성 중심 API가 아니라 속성 중심임을 알리기 위해) 아무 것도 하지 않습니다(둘 모두 속성 또는 속성으로 설정).
밑줄이나 대문자 ASCII 문자로 시작하는 XFoo의 모든 소품에 대해서는 아무 것도 하지 마십시오(그리고 경고를 표시할 수도 있습니다). 둘 다 사용자 정의 요소의 속성 이름을 지정하는 데 권장되는 방법이 아니므로 향후 의미 체계를 위해 해당 네임스페이스를 예약하십시오(예: 아래 #4 참조).
XFoo의 다른 모든 소품의 경우 클라이언트 측을 렌더링할 때 DOM 노드에서 속성으로 설정합니다. SSR의 경우 값이 기본이면 속성으로 렌더링합니다. 기본이 아닌 경우 렌더링을 건너뛰고 수화 중에 클라이언트 측 속성으로 설정합니다. 속성으로 SSR 렌더링의 경우 camelCaseToDashCase 이름입니다.
위 #2의 API를 통해 생성된 구성 요소의 경우 이벤트 리스너에 사용할 소품 이름을 예약하십시오. 예: 'events' 또는 'eventListeners' . 또는 잠재적인 사용자 정의 요소 속성 이름과 충돌하지 않으려면 '_eventListeners' 또는 'EventListeners' . XFoo 의 ReactDom 생성 구현은 이러한 이벤트 리스너를 DOM 노드에 자동으로 등록합니다.
극단적인 경우(예: 위의 구현이 바람직하지 않거나 충분하지 않은 사용자 지정 요소 사용)의 경우 앱 개발자는 필요한 모든 특별한 작업을 수행하기 위해 자체 React 구성 요소를 구현할 수 있습니다. 즉, ReactDOM.customElement() 를 사용할 필요가 없거나 확장할 수 있습니다.
위의 모든 동작을 원하지만 HTML 작성에 익숙한 사람들이 <div> 선호하는 비슷한 이유로 JSX가 소문자 사용자 정의 요소 이름( <x-foo /> 대신 <XFoo /> , <div> over <Div> ), 그들은 React.createElement()를 원숭이 패치할 수 있습니다. 아주 간단한 원숭이 패치가 될 것입니다. 첫 번째 인수를 취하고 이것이 원하는 사용자 정의 요소 이름과 일치하는 경우(특정 목록이든 모든 소문자와 하나 이상의 대시가 포함된 문자열이든 상관없이) ReactDOM.customElement() 를 호출합니다 ReactDOM.customElement() 를 입력하고 결과와 나머지 인수를 원래 React.createElement() 합니다.

effulgentsia 에 2017년 10월 27일

@developit @gaearon 둘 중 하나일 수 있습니다. "매핑"이 필요했다면 후크가 더 지속 가능하다고 생각합니다. 그러나 이것은 또한 Jason이 지적한 것처럼 ReactDOM의 코어에서 구현되는 경우 순 변경 사항을 보여주기 위한 것입니다.

treshugart 에 2017년 10월 27일

BC의 경우 React에서 소문자 사용자 정의 요소가 작동하는 방식에 대해 아무 것도 변경하지 마십시오. 즉, JSX는 React 16에서와 마찬가지로 React 17에서도 계속 동일한 방식으로 작동합니다. 또는 사소한 버그 수정이 필요한 경우 별도의 문제를 열어 이에 대해 논의하세요.

개인적으로 저는 <x-foo> 요소를 있는 그대로 사용하고 먼저 래핑할 필요 없이 속성을 쉽게 전달할 수 있기를 원합니다.

가능하다면 @sohpiebits 의 옵션 1(클라이언트 측 속성) 및 5(SSR용 구성)를 제안 하고 싶습니다. 나는 여전히 사람들이 이전 버전과의 호환성 보너스에 대해 option2(아마도 옵션 2 + 5?)를 재고할 것이라는 희망을 품고 있습니다.

@gaearon Trey의 제안이 ReactDOM 코어의 일부라면 의견이 바뀌나요? 도움이 된다면 예제를 더 구체화할 수 있지 않을까요?

robdodson 에 2017년 10월 28일

옵션 5에 대한 나의 주요 관심사는 상호 운용성을 허용하기 위해 많은 상용구를 만들고 DX를 깨는 것입니다. 모든 React 핵심 팀과 기여자가 원하는 영향을 미치지 않을 변경에 많은 시간을 보내는 것은 부끄러운 일입니다.

나는 React 팀이 _PropTypes_와 같은 리포지토리의 마지막 변경 사항을 처리하는 방법을 정말 좋아했습니다. 하나 이상의 스위치를 포함하는 계획을 생각하는 것이 좋을 것입니다. 개발자에게 향후 사용자 지정이 아닌 사용자 지정에 대해 수행할 수 있는 변경 사항을 교육하는 것입니다. 집단.

우리 모두를 만족시킬 솔루션은 이 옵션 중 일부를 _steps_, API 추가, 경고 및 사용 중단 또는 동작 변경으로 결합하는 솔루션이 될 것이라고 생각합니다.

옵션 5(경고 포함), 이후 옵션 2(필요한 래퍼 사용 중단 포함).

jeremenichelli 에 2017년 10월 30일

옵션 5(경고 포함), 이후 옵션 2(필요한 래퍼 사용 중단 포함).

나는 실제로 그 반대로 하는 것이 더 나은 일련의 단계가 될 것이라고 생각하고 있었습니다. 옵션 1 또는 2는 극적인 변화가 적기 때문에 선택합니다. 그리고 그것이 어떻게 진행되고 SSR 스토리가 웹 구성 요소에 대해 어떻게 보이기 시작하는지 측정합니다. 그런 다음 새 API와 프록시/래퍼 구성 요소 개념을 추가하기 때문에 옵션 5로 후속 조치를 취합니다.

robdodson 에 2017년 10월 30일

👍1

옵션 1의 주요 문제는 BC 브레이크가 꽤 크다는 것입니다. 옵션 2의 주요 문제는 요소 업그레이드가 완료된 시점에 따라 경쟁 조건이 있다는 것입니다. React만큼 널리 사용되는 프로젝트에 둘 중 하나가 진정으로 수용 가능한지 확신할 수 없습니다.

옵션 5의 가용성을 감안할 때 옵션 5가 아닌 사용을 훨씬 더 안전하지만 여전히 유용하게 개선할 수 있는지 궁금합니다. 예를 들어, 옵션 4의 역은 어떻습니까: domProperties 및 eventListeners 소품을 도입하면 다음과 같은 작업을 수행할 수 있습니다.

<x-foo 
  my-attr1={...} 
  domProperties={{myRichDataProperty: ...}} 
  eventListeners={{'a-custom-element-event':  e => console.log('yo')}} 
/>

대문자로 인해 domProperties 및 eventListeners 는 유효한 속성 이름 이 아니기 때문에 이것은 완전히 역호환

BC를 보존하는 것 외에도 이 접근 방식은 이해하기 쉽습니다. 속성 중심(React props가 요소 속성으로 처리됨을 의미)으로, 요소 이름 자체가 모두 소문자이고 대시가 있으므로 HTML 중심이라는 점을 감안할 때 적합합니다. 그러나 domProperties 는 리치 데이터를 전달하는 것과 같이 속성을 전달해야 하는 비교적 드문 경우를 위해 제공됩니다.

멘탈 모델을 속성 중심으로 전환하려는 사람들(옵션 1)을 위해 옵션 5 스타일 API가 필요할 수 있습니다.

const XFoo = ReactDOM.customElement('x-foo');
<XFoo prop1={} prop2={} data-foo={} aria-label={} />

이 구문을 사용하면 모든 소품이 속성으로 처리됩니다(옵션 1). "name"(XFoo) 요소도 JS 중심 규칙을 따르기 때문에 적합합니다. 나는 우리가 최소한 data-* 및 aria-* props를 속성으로 처리하기를 원한다고 생각합니다. 이 속성만 제한하거나 대시가 있는 모든 prop을 속성으로 처리하도록 일반화할 수 있습니다. 기인하다.

한편, SSR의 옵션 5 구성을 지원하기 위해 다음과 같이 구성 API를 ReactDOM.customElement 추가할 수 있습니다.

const XFoo = ReactDOM.customElement('x-foo', ssrConfiguration);

아마도 ssrConfiguration 는 @treshugart 의 코멘트 에 있는 ReactDOM.setAttribute 와 유사한 콜백 함수가 될 수 있습니까?

어떻게 생각하나요?

effulgentsia 에 2017년 10월 31일

👍4

@effulgentsia 나는 당신의 생각이 어디로 가는지 좋아합니다. 약간의 이름 변경: domProps / domEvents . 이것은 옵션 4에 매우 가깝습니다.

WRT SSR, 나는 React가 구성 요소가 추적하지 않는 경우 자체적으로 변경되는 속성을 존중할 수 있는 한 사용자 정의 요소 자체에서 SSR을 처리할 수 있다고 생각합니다. 이전에 요지를 게시했지만 편의상 다시 여기에 있습니다. https://gist.github.com/treshugart/6eff0da3c0bea886bb56589f743b78a6. 기본적으로 구성 요소는 서버에서 렌더링한 후 속성을 적용하고 클라이언트에서 다시 수화합니다. 웹 구성 요소에 대한 SSR은 가능하지만 솔루션은 여전히 표준 수준에서 논의되고 있으므로 제안의 이 부분을 기다리는 것이 가장 좋습니다.

treshugart 에 2017년 11월 01일

@effulgentsia 나도 당신이 향하고 있는 곳이 좋아요. @sophiebits , @gaearon do
이 방향에 대한 생각이 있으신가요?

2017년 10월 31일 화요일 오후 7시 33분 Trey Shugart [email protected] 은 다음과 같이 썼습니다.

@effulgentsia https://github.com/effulgentsia 나는 당신의 위치를 좋아합니다
생각이 가고 있습니다. 이름을 약간 변경하면 유용할 수 있습니다.
domProps / domEvents 등의 이름을 정렬합니다.
WRT 옵션 2, 최소한 이전 버전과 호환되며 대부분의 사용 사례를 해결합니다.
그러나 나는 대안을 제시하고 있습니다.
나는 SSR이
React는 구성 요소가 변경되는 속성을 존중할 수 있습니다.
그들을 추적하지 않습니다. 전에 요점을 게시했지만 여기에 다시 있습니다.
편의:
https://gist.github.com/treshugart/6eff0da3c0bea886bb56589f743b78a6.
기본적으로 구성 요소는 서버에서 렌더링한 후 속성을 적용합니다.
클라이언트에 다시 수분을 공급합니다. 웹 컴포넌트용 SSR은 가능하지만
솔루션은 여전히 표준 수준에서 논의되고 있으므로
여기에서 제안의 이 부분을 기다리는 것이 가장 좋습니다.
—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/facebook/react/issues/11347#issuecomment-340960798 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABBFDeiQhBWNGXNplbVV1zluYxT-ntFvks5sx9hngaJpZM4QD3Zn
.

robdodson 에 2017년 11월 01일

이름을 약간 변경: domProps / domEvents.

나는 그것들을 좋아한다. 또한 "dom"의 개념을 "ref"의 개념으로 대체하여 React에 더 관용적으로 만들 수 있는 방법이 있는지 브레인스토밍 중입니다. 즉, refProps / refEvents "ref"에 소품 및 이벤트 리스너를 연결하는 것이기 때문입니다.

그리고 this.props 내부에 새로운 특수 이름을 도입하는 대신 기존 ref JSX 속성을 오버로드하면 어떨까 하는 생각이 들었습니다. 현재 "ref"는 React 컴포넌트가 마운트 및 마운트 해제될 때 호출되는 함수입니다. 다음과 같이 객체도 허용하면 어떻게 될까요?

<x-foo my-attr-1={}
  ref={{
    props: ...
    events: ...
    mounted: ...
    unmounted: ...
  }}
/>

그냥 아이디어입니다.

effulgentsia 에 2017년 11월 01일

👍5

이 접근 방식이 정말 마음에 듭니다. :)

robdodson 에 2017년 11월 03일

이것에 대한 친절한 핑. @gaearon @sophiebits @effulgentsia 의 최근 제안에 대해 의견이 있으신 가요? 그것이 야구장에 있는지 아니면 비스타터에 있는지 궁금합니다.

robdodson 에 2017년 12월 12일

RFC 프로세스를 방금 열었습니다. RFC로 제출하도록 요청할 수 있습니까?
https://github.com/reactjs/rfcs

gaearon 에 2017년 12월 12일

domProperties 및 eventListeners "props"(또는 ref={{}} 객체 내에서 이에 상응하는 것)를 추가하지 않는 것이 좋습니다. 왜냐하면 사용자 정의 요소를 사용하는 것이 다른 모든 React 구성 요소와 달리 매우 부자연스럽기 때문입니다. 구성 요소 사용자가 속성과 속성 등의 차이점을 정확히 알아야 하는 경우에는 ReactDOM.createCustomElementType 스타일 솔루션으로 하는 것이 좋습니다. 그런 다음 구성 요소를 정확히 한 번 사용하면 비슷한 작업량(구성을 지정한 다음 한 번 사용)이지만 구성 요소를 여러 번 사용하면 구성 개체에 대해 매번 생각할 필요가 없습니다. 매번 구성을 지정하도록 요구하는 것은 내가 뭔가를 놓치고 있지 않는 한 깨끗한 사용자 정의 요소 통합을 갖는 목표를 무효화하는 것 같습니다.

sophiebits 에 2017년 12월 12일

@sophiebits 좋아, 그런 식으로 RFC를 작성할 수 있습니다. 10월 26일 에 처음으로 속성을 클라이언트 측으로 이동하고 사람들이 SSR에 대해 ReactDOM.createCustomElementType을 작성할 수 있도록 하거나 클라이언트가 속성/속성을 매핑하는 방법에 대해 정말 세분화된 제어를 원하는 경우에 대해 어떻게 생각하십니까? ?

robdodson 에 2017년 12월 12일

👍3

최소한 createCustomElementType 스타일을 사용하면 라이브러리에서 API를 쉽게 매핑할 수 있습니다. 즉, 우리의 skatejs/renderer-react는 props 쉽게 받아 React에 대한 사용자 정의 요소를 구성할 수 있습니다. 이런 종류의 바닐라 사람들은 추상화 또는 약간의 작업 없이도 높고 건조합니다. 나는 세분화된 제어를 허용하면서 안전한 기본값에 대한 Rob의 제안을 좋아합니다. 그게 효과가 있을까요?

treshugart 에 2017년 12월 13일

@robdodson 나는 그것에

sophiebits 에 2017년 12월 13일

👍1

옵션 3은 지금까지 최고의 옵션이며 SSR과 함께 작동할 수 있습니다. 방법에 대한 아이디어를 설명하겠습니다.

지금까지 3개를 제외한 모든 옵션을 단독으로,

React 소스 외부의 모든 사람에게 높은 유지 관리 부담을 가중시키거나
또는 전체 우주의 모든 사용자 정의 요소 작성자가 React 관련 규칙을 따르도록 강제합니다.

다음은 우리 모두가 동의하는 보편적인 규칙입니다.

setAttribute 를 사용하여 특성을 설정하는 것은 선언적 HTML 특성과 1:1로 일치하는 방식으로 데이터를 요소에 전달하는 가장 표준적인 방법입니다. 이것은 우주의 법칙으로 항상 100% 작동해야 하므로 데이터를 요소에 전달하는 유일한 100% 보장된 방법입니다.
어떤 사람들은 그것이 문자열만을 위해 설계된 것에 만족하지 않습니다.
일부 요소(나는 _일부 요소만_ 반복)는 특정 속성에 매핑되는 개체 속성을 통해 값을 허용합니다. 이것은 100% 신뢰할 수 있는 것이 _ 아닙니다 _.
어떤 사람들은 비문자열을 받아들일 수 있기 때문에 객체 속성을 좋아합니다.

따라서 최소한 React가 _우주의 모든 단일 사용자 정의 요소로 100% 작동하고

React는 그것이 신이 아니라는 것을 깨달아야 합니다. 사람들이 react 외에 사용하는 다른 많은 라이브러리가 있습니다.
따라서 반작용 샤 우드 _by default_ 단지 통해 데이터 전달 setAttribute 즉 100 % 표준 때문입니다.
사용자 정의 요소 저자 / 연장 덮어 쓸 수 있다는 사실을 받아 들여야 반응 setAttribute 만들고, 자신의 클래스 정의 메소드를 setAttribute 문자열이 아닌 다른 일을 동의합니다. 대표적인 예로 A-frame과 같은 라이브러리를 들 수 있습니다.
React는 사용자 정의 요소 작성자가 사용자 정의 요소가 _React뿐만 아니라_ 모든 가능한 라이브러리와 함께 작동하기를 원하는 경우 해당 작성자는 setAttribute 에 의존하여 기본적으로 모든 것과 호환되는 요소를 만드는 것을 수락 해야 합니다. 모든 라이브러리가 속성에 의존하면 전체 유니버스가 서로 작동합니다. _이것에 대해 어떤 경우도 없고, 반대도 없습니다!_ (w3c/whatwg가 약간의 큰 변경을 가하지 않는 한)

Soooooooo , 즉, 우리는 최소한

https://github.com/facebook/react/issues/10070 수정 (내가 리디렉션 된 곳)
이렇게 하면 표준에 더 가까워집니다.

그런 다음 때때로 객체 속성 API가 있는 요소의 의미에 대해 생각할 수 있습니다.

개발자는 setAttribute 가 항상 작동한다는 것을 알고 사용할 수 있습니다.
개발자는 때때로 개체 속성을 활용할 수 있습니다.
개발자는 항상 주어진 요소(사용자 지정 여부)에 대해 개체 속성 인터페이스가 존재하는지 여부를 알고 있어야 합니다.
객체 속성 인터페이스는 속성과 1:1로 매핑할 필요가 없는 대체 인터페이스입니다.

따라서 속성과 속성에 대한 이러한 지식을 바탕으로 _표준을 100% 확장하고 우주의 법칙을 존중하기 를 과 같아야 합니다.

속성이 기본적으로 100% 작동하도록 허용합니다. 그이 수단 <x-foo blah="blah" /> 에 default_지도 _by한다 setAttribute 하고 _unchanged_ 따라 값을 전달합니다. 이는 중단되지 않는 변경 사항입니다. 사실, 이는 의미 없는 "[object Object]" 문자열이 전달되는 결과를 초래하는 수정 변경 사항입니다.
사용자가 어떤 객체 속성 인터페이스가 존재하는지 알고 있고 이러한 인터페이스를 명시적으로 사용하려는 경우 React 사용자가 _ props를 사용하도록 하는 다른 방법을 생각해

sigil을 사용하는 옵션 3(추가 구문은 솔직히 배우기 어렵지 않음)을 사용하는 것이 이상에 가장 가까운 솔루션인 것 같습니다. 이 SO 질문에 따르면 사용 가능한 유일한 기호는 = 이지만 & ( \& 와 같은 이스케이프 가능한 형식 사용)와 같은 항목에 정착하는 것이 더 읽기 쉽습니다. 예를 들어 구체적으로 소품을 원하는 경우:

<x-foo &blah="blah" />

WHATWG HTML 구문 사양에서 다루는 대부분의 다른 문자는 작동해야 하며 작동하기를 바랍니다. 그러나 이는 다른 주제입니다.

옵션 3은 지금까지 최고의 옵션입니다.

클라이언트에서 수화를 사용하지 않고 따라서 소품이 SSR에서 의미가 없다면 오 글쎄요. 이전에는 작동하지 않았으며 지금은 작동하지 않아도 됩니다. PHP 스타일 또는 Java 스타일 SSR은 수화 없이 정적 HTML을 전송하며 속성에 100% 의존합니다. 즉, React SSR을 사용하는 경우 클라이언트 측 수화를 사용하고 수화를 원하지 않는 경우 이 경우 props를 사용하지 않아야 한다는 사실을 알고 있어야 합니다. _ 간단합니다. 반응해야 할 모든 것은 문서에서 이 경고를 명확하게 하는 것입니다._

하지만!!! 그게 다가 아니야! 사람들에게 더 많은 제어 권한을 제공하기 위해 여전히 옵션 5의 기능을 포함할 수 있습니다. 옵션 5와 같은 API를 사용하면

어떤 사람들은 일부 속성이 props에 매핑되는 방법을 구성할 수 있습니다.
그리고 일부 소품이 속성에 매핑되는 방법. 이것은 사람들이 SSR이 수화되지 않은 유형의 SSR에도 작동하도록 도울 수 있습니다!
우리는 사람들이 "이 속성이 작성되면 실제로 이 prop에 전달하지만 SSR인 경우에는 prop에 전달하지 마십시오" 또는 "SSR 동안에만 이 속성에 이 prop을 전달하고 그렇지 않으면 무엇을 합니까?"라고 정의하도록 할 수 있습니다. sigil" 등을 사용하여 지정했습니다.

결국 다음은 작동하는 솔루션처럼 보입니다.

setAttribute 옵션 3은 기본적으로 뒤에서 사용됩니다.
React가 사람들의 방해가 되지 않도록 #10070을 수정했습니다.
SSR, 클라이언트 또는 둘 다를 조정하는 방법을 포함하여 실제로 필요한 경우 추가 조정을 위한 옵션 5와 같은 API.

새해 복 많이 받으세요!

trusktr 에 2018년 01월 05일

👍4

위의 몇 가지 사항에 답하고 싶지만 이 스레드가 이미 _믿을 수 없을 정도로_ 길다는 사실이 두렵습니다. 그래서 더 길어져서 죄송합니다 :P

다음은 우리 모두가 동의하는 보편적인 규칙입니다.

setAttribute를 사용하여 특성을 설정하는 것은 선언적 HTML 특성과 1:1로 일치하는 방식으로 데이터를 요소에 전달하는 가장 표준적인 방법입니다. 이것은 우주의 법칙으로 항상 100% 작동해야 하므로 데이터를 요소에 전달하는 유일한 100% 보장된 방법입니다.

이것은 완전히 사실이 아닙니다. 플랫폼에는 사용자 정의 요소가 속성 인터페이스를 노출하도록 강제하는 것이 없습니다. JS 속성만 허용하는 속성을 쉽게 만들 수 있습니다. 따라서 "데이터를 전달하는 보장된 방법"이 아닙니다. 시행 메커니즘이 없다는 것은 100% 확실하게 스타일(HTML 속성 또는 JS 속성)에 의존할 수 없다는 것을 의미합니다.

어떤 사람들은 그것이 문자열만을 위해 설계된 것에 만족하지 않습니다.
일부 요소(일부 요소만 반복)는 특정 속성에 매핑되는 개체 속성을 통해 값을 허용합니다. 이것은 100% 신뢰할 수 있는 것이 아닙니다.

우리는 사람들이 객체/배열과 같은 풍부한 데이터를 허용하는 속성에 대한 속성을 생성하는 것을 귀찮게 하지 않도록 권장합니다. 이는 일부 데이터를 속성 문자열로 다시 직렬화할 수 없기 때문입니다. 예를 들어 개체 속성 중 하나가 DOM 노드에 대한 참조인 경우 실제로 문자열화할 수 없습니다. 또한 개체를 문자열화하고 재분석하면 개체의 ID가 손실됩니다. 즉, 다른 POJO에 대한 참조가 있는 경우 완전히 새로운 객체를 생성했기 때문에 해당 참조를 실제로 사용할 수 없습니다.

어떤 사람들은 비문자열을 받아들일 수 있기 때문에 객체 속성을 좋아합니다.

따라서 React는 100% 표준이기 때문에 기본적으로 setAttribute를 통해 데이터를 전달해야 합니다.

JavaScript 속성은 표준과 동일합니다. 대부분의 HTML 요소는 속성과 해당 속성 인터페이스를 모두 노출합니다. 예: <img src=""> 또는 HTMLImageElement.src .

React는 Custom Element 작성자가 클래스 정의에서 setAttribute 메소드를 확장/재정의할 수 있다는 사실을 받아들여야 합니다. setAttribute는 문자열 이외의 것을 허용합니다.

작성자는 그렇게 할 수 있지만 실제로는 JS 속성을 사용하는 것보다 훨씬 "비표준"인 것 같습니다. 또한 요소 구문 분석 및 복제와 관련된 이상한 문제에 노출될 수 있습니다.

React는 사용자 정의 요소 작성자가 사용자 정의 요소가 React뿐만 아니라 모든 가능한 라이브러리와 함께 작동하기를 원하는 경우 해당 작성자는 기본적으로 모든 것과 호환되는 요소를 만들기 위해 setAttribute에 의존하고 기본적으로 모든 라이브러리가 속성에 의존하는 경우 수락해야 합니다. , 그러면 온 우주가 서로 협력할 것입니다. 이것에 대해서는 if, and, buts가 없습니다! (w3c/whatww가 큰 변화를 주지 않는 한)

사용자 정의 요소(예: Angular)에 JS 속성을 설정하는 것을 선호하는 다른 라이브러리가 있기 때문에 이 결론에 어떻게 도달했는지 잘 모르겠습니다. 최대의 호환성을 위해 작성자는 JS 속성으로 속성을 지원해야 합니다. 그것은 가능한 사용의 가장 큰 표면적을 덮을 것입니다. Polymer로 생성된 모든 요소는 기본적으로 이 작업을 수행합니다.

속성이 기본적으로 100% 작동하도록 허용합니다. 이것은 의미합니다 기본적으로 setAttribute에 매핑되고 변경되지 않은 값을 전달해야 합니다. 이는 중단되지 않는 변경 사항입니다. 사실, 그렇지 않으면 의미 없는 "[object Object]" 문자열이 전달되는 수정 변경 사항입니다.

나는 React가 실제로 값을 변경하지 않고 전달하는 _is_라고 생각합니다. setAttribute('foo', {some: object}) 호출하면 [object Object] 됩니다. 그들이 개체에 대해 JSON.stringify() 를 호출하도록 제안하지 않는 한? 그러나 그 객체는 "변경되지 않은" 것이 아닙니다. setAttribute() 을(를) 재정의한 작성자에게 의존하고 있는 것 같습니다. DOM을 원숭이 패치하는 대신 해당 JS 속성을 생성하도록 권장하는 것이 더 그럴듯합니다.

robdodson 에 2018년 01월 22일

👍2

나는 React가 실제로 값을 변경하지 않고 전달하는 _is_라고 생각합니다. setAttribute('foo', {some: object}) 호출하면 [object Object]

React는 setAttribute 전달하기 전에 값을 문자열로 강제 변환합니다.

https://github.com/facebook/react/blob/4d6540893809cbecb5d7490a77ec7ad32e2aeeb3/packages/react-dom/src/client/DOMPropertyOperations.js#L136

그리고

https://github.com/facebook/react/blob/4d6540893809cbecb5d7490a77ec7ad32e2aeeb3/packages/react-dom/src/client/DOMPropertyOperations.js#L166

나는 기본적으로 당신이 말한 모든 것에 동의합니다.

우리는 사람들이 양방향으로 일을 한다는 데 동의하고 모든 사람이 어느 한 방향으로만 하도록 강요하는 표준이 없기 때문에 여전히 생각합니다.

setAttribute 가 기본적으로 사용되는 옵션 3과 인스턴스 속성을 사용하도록 지정하기 위한 인장,
React가 args를 문자열로 강제하지 않도록 #10070을 수정했습니다.
및 옵션 5, 미세 조정을 위한 API

옵션 5가 잘 수행되면 SSR 솔루션에 대한 수화는 옵션 5 API를 사용하여 지정할 수 있는 속성 또는 소품에 데이터를 매핑할 수 있습니다.

trusktr 에 2018년 01월 23일

React는 setAttribute에 전달하기 전에 값을 문자열로 강제 변환합니다.

알 겠어요. 대부분의 사람들은 사용자 정의 toString() 정의하지 않기 때문에 기본값은 [object Object] 입니다.

robdodson 에 2018년 01월 23일

대부분의 사람들은 사용자 정의 toString() 정의하지 않기 때문에 기본값은 [object Object] 입니다.

마치 내가 하는 것처럼

const div = document.createElement('div')
div.setAttribute('foo', {a:1, b:2, c:3})

결과는

<div foo="[object Object]"></div>

분명히 웹 개발자로서 우리는 비문자열을 요소 속성에 전달할 때 어떤 일이 발생하는지 알고 있어야 합니다. 예를 들어 비문자열을 A-Frame 요소에 전달할 수 있다는 것을 알고 있으며 라이브러리가 방해받지 않고 자유롭게 해야 합니다.

trusktr 에 2018년 01월 23일

React는 그것이 신이 아니라는 것을 깨달아야 합니다. 사람들이 react 외에 사용하는 다른 많은 라이브러리가 있습니다.

이것은 불필요하게 비꼬는 것입니다. 이 스레드에서 우리는 이것에 관심이 있지만 사용자 정의 요소 디자인을 취할 위치에 대한 다양한 옵션과 비전이 있음을 알 수 있습니다. 무엇을 해야 하는지 분명하지 않습니다.

sebmarkbage 에 2018년 01월 23일

👍2 👎1

@sebmarkbage 죄송합니다. 저는

내가 의미하는 바는 React가 매우 인기가 있다는 것입니다. 그래서 React는 다른 곳에서는 작동하지 않을 수 있는 특정한 방식으로 일을 하도록 사람들을 흔들 수 있는 가능성이 있습니다. t 모든 사용자 정의 요소와 함께 작동).

React는 현재 요소 속성에 전달된 모든 값을 문자열로 변환합니다. 예를 들어 React가 이 작업을 수행하지 않았다면 (문자열 문제를 해결하는) frame-react 가

React가 일반 JavaScript에서와 같이 데이터를 요소에 전달하는 방법을 선택할 수 있게 해준다면 가장 만족스러운 사용자가 될 것입니다. 😊

다시 한 번 말씀드리지만 죄송합니다. 다음에 한번 더 생각해봐야겠습니다.

trusktr 에 2018년 01월 23일

👍9 🎉4

이에 대한 RFC PR에 대한 설명 을 추가했습니다. 사용자 정의 요소와 그 속성을 안정적으로 추론하기 위한 더 간단한 모델뿐만 아니라 제안된 내용을 다루기 때문에 논의할 가치가 있다고 생각합니다. 다시 하이브리드 접근 방식으로 전환하지만 대부분의 사용 사례에 대해 구성이 필요 없는 통합 방식을 제공합니다.

treshugart 에 2018년 02월 02일

이 기능이 React에서 구현되는 것을 보고 싶습니다. React를 훌륭하게 만드는 노력에 감사드립니다.

jfhector 에 2019년 04월 23일

👍15

이 RFC에 대한 업데이트가 있습니까?

volmerf 에 2019년 05월 07일

👍27 👀13

사용자 정의 요소 라이브러리가 정말 좋아지고 있으며 내 React 앱에서 사용하고 싶습니다. 아직 소식이 없나요? 사용자 정의 요소를 래핑하고 나중에 다시 구문 분석하기 위해 해당 내용을 문자열화하는 것은 Vue 및 Angular가 기본적으로 구성 요소를 쉽게 처리한다는 점을 고려할 때 상당히 실행 불가능한 솔루션입니다.

BBKolton 에 2019년 08월 01일

👍27

이 문제에 대한 업데이트가 있습니까?

brion-fuller 에 2019년 08월 06일

👍15 👎1

나도 해킹에 의존하지 않고 사용자 정의 요소 라이브러리를 사용하고 싶습니다. 이 문제가 해결되었으면 합니다.

mgolub2 에 2019년 08월 19일

👍18

@mgolub2 React 팀은 웹 커뮤니티가 원하는 것이 무엇인지 신경 쓰지 않습니다. 웹 구성 요소는 이제 널리 지원되는 표준이며 2년이 지난 후에도 이 표준을 지원하라는 팀의 신호가 없습니다.

equinusocio 에 2019년 09월 17일

👎3 👍2 ❤1

안녕하세요 여러분, 저는 이 문제를 해결하기 위해 다음 두 줄을 변경하여 풀 리퀘스트를 시작했습니다: https://github.com/facebook/react/pull/16899

이를 통해 사용자 정의 요소 작성자는 다음과 같은 작업을 수행할 수 있습니다.

class MyElement extends HTMLElement {
  setAttribute(name, value) {
    // default to existing behavior with strings
    if (typeof value === 'string')
      return super.setAttribute(name, value)

    // but now a custom element author can decide what to do with non-string values.
    if (value instanceof SomeCoolObject) { /*...*/ }
  }
}

확장된 setAttribute 메서드의 모양에는 많은 변형이 있으며 이는 하나의 작은 예일 뿐입니다.

React 팀, 사용자 정의 요소 작성자는 경우에 따라 DOM의 기본 속성 처리를 우회하기 때문에(값이 문자열이 아닌 경우 fe) 그렇게 해서는 안 된다고 주장할 수 있습니다. 당신이 그 의견을 가지고 있다고 해도 그것이 사용자 정의 요소 작성자가 __ 사용자 정의 __ 요소로 할 수 있는 일을 방해해야 한다는 의미는 아닙니다.

React는 기존 DOM API가 어떻게 사용되는지에 대해 의견을 제시해서는 안 됩니다. React는 DOM을 조작하기 위한 도구이며 DOM에 대해 수행할 수 있는 작업에 대해 의견을 제시해서는 안 됩니다. "데이터가 DOM으로 흐르는 방식"이란 데이터를 변경하지 않고 데이터가 거기에 도달하는 데 걸리는 경로를 의미합니다(작성자의 개체를 문자열로 변환하는 것은 작성자의 데이터를 변경하는 것입니다).

작성자의 데이터를 변경하려는 이유는 무엇입니까? DOM을 조작하려는 사람이 DOM에 전달할 데이터를 알고 있다고 가정할 수 없는 이유는 무엇입니까?

trusktr 에 2019년 09월 26일

👍1

@trusktr 나는 이것이 https://github.com/facebook/react/issues/10070 에서 논의되었다고 생각합니다.

사용자 정의 요소 작성자에게 setAttribute 와 같은 내장 메서드를 재정의하라고 말하는 것에 대해 사람들에게 정말 주의를 주고 싶습니다. 우리가 원숭이 패치를 할 의도가 아니라고 생각합니다. cc @gaearon

robdodson 에 2019년 09월 26일

👍7

이와 같은 하위 클래스에서 setAttribute 를 재정의하는 것은 무해합니다(원숭이 패치가 아님). 그러나 내가 언급했듯이, 그것이 반드시 React 라이브러리의 작업이 아닌 경우 React가 그것에 대해 지시해야 하는 이유는 무엇입니까? 우리는 (장애 없이) DOM을 조작하기 위해 React를 사용하기를 원합니다.

성능 향상을 위해 수동으로 el.setAttribute() 를 사용해야 하는 경우에도 개발 환경이 악화됩니다.

React 팀이 setAttribute 로 전달된 모든 것을 문자열로 변환하여 엄청난 위험에서 많은 사람들을 구하고 있다고 생각하지 않습니다.

다른 솔루션이 더 나을 수 있다는 데 동의합니다. 예를 들어 JSX 사양을 새로운 구문으로 업데이트하지만 시간이 오래 걸리는 것 같습니다.

자동 문자열 변환을 없애면 커뮤니티가 잃는 것은 무엇입니까? React 팀은 무엇을 잃습니까?

React 팀은 나중에 더 나은 솔루션으로 상황을 개선할 수 있습니다.

trusktr 에 2019년 09월 26일

최소한 단순히 문자열화를 우회할 수 있는 옵션을 제공하지 않는 이유는 무엇입니까? 그것은 당신이 기꺼이 고려할 수 있는 것입니까?

trusktr 에 2019년 09월 26일

사용자 정의 요소 작성자에게 setAttribute 와 같은 내장 메서드를 재정의하라고 말하는 것에 대해 사람들에게 정말 주의를 주고 싶습니다.

그 이유에 대해 좋은 이유를 제시할 수 있습니까?

trusktr 에 2019년 09월 26일

이것은 청어처럼 보입니다. "사용자 정의 요소를 작성하는 모든 사람이 자신의 요소에 특정 동작이 있는 메서드를 첨부하도록 설득"은 DOM 요소에 속성을 설정하는 방법에 대한 이 문제에 대한 해결책이 아닙니다.

TehShrike 에 2019년 09월 26일

👍4

@trusktr

그 이유에 대해 좋은 이유를 제시할 수 있습니까?

웹 구성 요소는 표준입니다. 따라서 표준의 파생물도 표준을 준수해야 합니다.

그러나 setAttribute 재정의하는 것은 이 조건에 맞지 않습니다. 기본적으로 웹 구성 요소와 함께 작동하는 다른 많은 프레임워크가 있지만 React에 대해서만 해킹을 생성합니다. 따라서 React와 전혀 작동하지 않는 경우에도 React 핵을 소비해야 합니다. 나는 그것이 올바른 해결책이라고 생각하지 않습니다.

다음으로, 표준 방법을 패치하는 것은 잘못된 접근 방식이라는 것은 잘 알려져 있습니다. setAttribute 재정의하면 최종 사용자가 사용하려고 할 때 혼란스러워할 수 있는 원래 동작이 변경됩니다. 모든 사람은 표준이 표준으로 작동하기를 기대하며 사용자 지정 요소도 예외는 아닙니다. HTMLElement 동작을 상속하기 때문입니다. React와 함께 작동할 수도 있지만 다른 모든 사용자를 위한 함정을 만듭니다. 예를 들어 프레임워크 없이 웹 컴포넌트를 사용하는 경우 setAttribute 가 많이 호출될 수 있습니다. 사용자 정의 요소 개발자가 이 접근 방식으로 발을 떼는 데 동의할지 의심스럽습니다.

개인적으로, 어떤 종류의 React 래퍼가 훨씬 더 유망해 보인다고 생각합니다.

Lodin 에 2019년 09월 26일

👍17

여러분, 기다리는 동안 React https://www.npmjs.com/package/reactify-wc 에서 웹 구성 요소를 래핑하기 위한 shim을 만들었습니다.

import React from "react";
import reactifyWc from "reactify-wc";

// Import your web component. This one defines a tag called 'vaadin-button'
import "@vaadin/vaadin-button";

const onClick = () => console.log('hello world');

const VaadinButton = reactifyWc("vaadin-button");

export const MyReactComponent = () => (
  <>
    <h1>Hello world</h1>
    <VaadinButton onClick={onClick}>
      Click me!
    </VaadinButton>
  </>
)

이것이 도움이 되기를 바랍니다.

BBKolton 에 2019년 10월 02일

👍27 ❤5 🎉4

여러분, 기다리는 동안 React https://www.npmjs.com/package/reactify-wc 에서 웹 구성 요소를 래핑하기 위한 shim을 만들었습니다.
import React from "react";
import reactifyWc from "reactify-wc";

// Import your web component. This one defines a tag called 'vaadin-button'
import "@vaadin/vaadin-button";

const onClick = () => console.log('hello world');

const VaadinButton = reactifyWc("vaadin-button");

export const MyReactComponent = () => (
  <>
    <h1>Hello world</h1>
    <VaadinButton onClick={onClick}>
      Click me!
    </VaadinButton>
  </>
)
이것이 도움이 되기를 바랍니다.
(이것은 내가 OSS에 처음으로 진출한 것이고, 사무실 밖에서 무언가를 공개한 최초의 것 중 하나입니다. 건설적인 비판은 더할 나위 없이 환영입니다 😄 )

훌륭한 래퍼 :)

Stencil로 웹 구성 요소를 빌드하면 React에서 이 문제가 해결된다는 점도 언급할 가치가 있습니다. https://stenciljs.com/docs/faq#can -data-be-passed-to-web-components-

matsgm 에 2020년 01월 05일

@matsgm Stencil을 사용한 빌드가 도움이 되어 기쁩니다. 그러나 우리 경험에 따르면 Stencil은 다른 웹 구성 요소 프레임워크, 특히 Polymer에서 제대로 작동하지 않는 것으로 입증되었으며 빌드 도구, 지원 및 일반 기능 사이의 6가지 다른 문제로 인해 짜증이 났습니다. 귀하의 마일리지가 다를 수 있습니다 :)

BBKolton 에 2020년 01월 07일

👍2

이 스레드로 최신 정보를 얻으려고 합니다. 최종 해결책은 무엇입니까?

어떤 면에서 저는 매우 혼란스러울 수 있는 마술적 발견보다 속성, 소품, 이벤트를 명시적으로 정의하는 것을 좋아합니다.

예를 들어 snabbdom 은 명시적인 최상위 네임스페이스를 사용하므로 무엇이 어디로 가는지 쉽게 알 수 있습니다. 더 빠른 실행을 위한 문자열 조작은 없습니다. 예를 들어 onClick => click 에서 접미사를 자르는 것은 여전히 성능이 좋습니다.

<input attrs={{placeholder: `heyo`}} style={{color: `inherit`}} class={{hello: true, world: false}} on={{click: this.handleClick}} props={{value: `blah`}} />

attr = (attr, val) => elem.setAttribute(attr, val);
prop = (prop, val) => elem[prop] = val;
on  = (event, handler) => elem.addEventListener(event, handler)
style = (prop, val) => elem.style[prop] = val;
class = (name, isSet) => isSet ? elem.classList.add(name) : elem.classList.remove(val)
dataset = (key, val) => elem.dataset[key] = val;

JSX가 점 구문으로 네임스페이스를 지원했으면 합니다. 이것은 props가 기본 네임스페이스가 되며 간단히 작성할 수 있음을 의미합니다.

<div tabIndex={-1} attr.title={"abcd"} on.click={handler} style.opacity={1} class.world={true} />`

참고로 @sebmarkbage ^

nojvek 에 2020년 03월 27일

👍3

const whatever = 'Whatever';
const obj = { a: 1, b: 2 };
const reactComponent = (props) => (
<div>
  ...
  <custom-element attr="{whatever}" someProp={obj} />
  { /* double quotes for attributes */ }
  { /* no quotes for properties */ }
</div>
);

이것은 React JSX Pragma 파서를 수정하여 달성할 수 있습니다.

추가 옵션은 propeties (또는 반응 팬의 경우 props )을 자산 전달에 대한 지정된 단어로 유지하는 것입니다.

eavichay 에 2020년 07월 14일

👍2

오늘 17.0이 출시되었으므로 이 문제가 언제 해결되는지 상태를 반영하도록 이 문제를 업데이트할 수 있습니까?

TimvdLippe 에 2020년 10월 20일

👍3

응. 우리는 원래 React 17을 더 많은 지원 중단이 제거되고 새로운 기능이 포함된 릴리스로 계획했습니다. 그러나 오래된 코드베이스가 모든 코드를 업데이트하는 것은 그다지 현실적이지 않으며, 이것이 우리가 하나의 중요한 주요 변경 사항(이벤트는 문서가 아닌 루트 요소에 첨부됨)에만 초점을 맞춘 React 17을 출시하기로 결정한 이유입니다. ). 이는 오래된 앱이 React 17에 영원히 남아 있고 그 중 일부만 18+로 업데이트할 수 있도록 하기 위한 것입니다.

이 특정 기능이 17에 들어갈 것이라고 말하는 것이 실망스럽다는 것을 압니다. 하지만 원래 17에 대해 계획했던 모든 기능도 18로 옮겨졌다는 것을 알게 되실 것입니다. 17은 특별한 디딤돌 발매입니다. 이를 통해 18에서 더 공격적인 주요 변경 사항을 만들 수 있습니다. 앞으로 명확한 경로가 있다면 이 변경 사항을 포함할 수 있습니다.

이러한 옵션 중 어느 것이 더 바람직한지에 대한 WC 커뮤니티의 최신 합의가 무엇인지 잘 모르겠습니다. 그것은 그들 모두가 (그 일을 위해 @robdodson에 큰 소품) 생각을 적어이 매우 도움이됩니다. 이 스레드가 작성된 이후 이러한 옵션에 대한 사람들의 의견이 발전했는지, 방향을 선택하는 데 도움이 될 수 있는 새로운 정보가 있는지 궁금합니다.

gaearon 에 2020년 10월 21일

👍4

저는 WC 커뮤니티가 선호하는 옵션을 변경했다고 생각하지 않습니다. 여전히 옵션 3입니다. @developit 은 Preact가 사용자 지정 요소와 어떻게 호환되는지에 대해 더 많이 말할 수 있습니다. 이는 React에서도 흥미로울 수 있습니다. 프레임워크가 사용자 정의 요소에 (복잡한) 데이터를 전달하는 것과 어떻게 호환되는지에 대한 일반적인 개요를 보려면 https://custom-elements-everywhere.com/ 에 모든 세부 정보가 있습니다.

TimvdLippe 에 2020년 10월 21일

👍1

https://github.com/vuejs/vue/issues/7582 에서 Vue는 sigil을 사용하기로 선택했고 "."를 선택했습니다. 접두사로 (Glimmer의 "@"가 아님).

https://github.com/vuejs/vue/issues/7582#issuecomment -362943450에서 @trusktr 은 가장 정확한 SSR 구현이 sigil'd 속성을 SSR'd HTML의 속성으로 렌더링하지 않는 것이라고 제안했습니다. 대신 수화 중에 JS를 통해 속성으로 설정하십시오.

effulgentsia 에 2020년 10월 21일

이 특정 기능만을 위해 새로운 JSX 구문을 도입할 가능성은 거의 없다고 생각합니다.

옵션(5)의 보다 일반적인 버전이 테이블에 있을 수 있는 경우 옵션(3)을 수행할 가치가 있는지에 대한 질문도 있습니다. 즉, 옵션 (5)는 사용자 지정 마운트/업데이트/마운트 해제/수화 동작으로 사용자 지정 저수준 React 노드를 선언하는 저수준 메커니즘이 될 수 있습니다. 사용자 정의 요소 자체에만 국한되지는 않습니다(사용 사례 중 하나일지라도).

gaearon 에 2020년 10월 21일

👍1

이 특정 기능에 대해 완전히 새로운 JSX 구문을 도입하는 대신 보다 일반적인 JSX를 도입하고 이를 사용하여 사용자 정의 속성을 정의하는 것은 어떻습니까?

나는 오래전에 JSX에 ECMAScript의 계산된 속성 구문을 추가하는 것을 제안했고(facebook/jsx#108) 일반적으로 구문에 유용한 추가가 될 것이라고 생각합니다.

계산된 속성 구문을 사용할 수 있는 경우 계산된 속성 구문과 기호 또는 접두어가 붙은 문자열을 사용하여 속성을 정의할 수 있는 가능성이 열려 있습니다.

예를 들어:

import {property} from 'react';
// ...
<custom-img [property('src')]="corgi.jpg" [property('hiResSrc')]="[email protected]" width="100%">

dantman 에 2020년 10월 21일

@dantman 이 제안은 서버 렌더링 및 수화를 어떻게 처리합니까?

gaearon 에 2020년 10월 21일

WC 커뮤니티의 누구도 옵션 5를 원하지 않는다고 생각합니다.

사용자 정의 요소에 대한 사용자 정의 React 래퍼 작성을 패치하는 현재 관행과 실제로 다르지 않습니다. 이 접근 방식의 큰 단점은 구성 요소 작성자에게 특별한 경우의 React 또는 구성 요소 소비자에게 특별한 경우의 사용자 지정 요소에 대한 부담을 주며 둘 다 필요하지 않아야 한다는 것입니다.

justinfagnani 에 2020년 10월 21일

👍2 ❤1

서버 렌더링 및 수화에 대해 어떻게 생각하십니까? 명시적 구성이 없는 경우 어떤 경험적 방법이 바람직합니까? WC 커뮤니티에서 일반적으로 수행되는 방식이 통합되었습니까? 이 RFC를 다시 읽었는데 이 주제에 대한 세부 정보가 없는 것 같습니다. 그러나 특히 React가 서버 렌더링에 더 중점을 두는 방향으로 이동함에 따라 매우 중요합니다.

gaearon 에 2020년 10월 21일

@gaearon 필요한 것이 무엇인지 알기에 충분한 수화 및 사용자 정의 속성을 알지 못합니다. 이것은 주로 구문 제안입니다.

일반적으로 property(propertyName) 는 구현 방법에 따라 접두어가 붙은 문자열(예: '__REACT_INTERNAL_PROP__$' + propertyName )을 출력하거나 Symbol을 생성하고 "symbol => propertyName" 연관을 저장할 수 있다는 것입니다. 지도.

나중에 해당 맵을 클라이언트와 통신해야 하는 경우 문제가 될 수 있습니다.

그러나 내 대략적인 이해에 따르면 속성은 서버에서 처리할 수 있는 것이 아니며 수화에는 클라이언트 코드가 포함되므로 이에 대한 계획이 무엇인지 잘 모르겠습니다. 내 제안에 관해서는 그 문제를 해결하기 위해 어떤 계획을 가지고 있든 적용할 수 있을 것입니다. 서버의 속성에 반응하도록 하려는 것이 있다면 property 의해 생성된 속성 중 하나를 볼 때만 그렇게 할 수 있습니다.

dantman 에 2020년 10월 21일

웹 구성 요소 라이브러리 작성자로서 옵션 5는 편리한 선택이 아닙니다. 각 프레임워크 및 구성 요소에 대한 스키마를 명시적으로 정의하지 않고도 사용자 지정 요소를 만들고 싶습니다. 그리고 많은 사용자 정의 요소 작성자는 이것을 하지 않아 React 개발자에게 부담을 줍니다.

옵션 5로 승자는 없습니다. 😕

claviska 에 2020년 10월 21일

👍2

@claviska 서버 렌더링 및 수화 작업이 보다 암시적인 접근 방식으로 작동하는 방식에 대한 의견이 있습니까?

gaearon 에 2020년 10월 21일

@gaearon SSR은 사용자 정의 요소가 SSR을 지원하는 경우와 지원하지 않는 경우의 두 가지 상황으로 세분화됩니다.

SSR을 지원하지 않는 요소의 경우 서버의 속성 설정은 중요하지 않습니다. id 및 className 와 같은 내장 반영 속성을 제외하고는 삭제할 수 있으며 클라이언트에서만 쓸 수 있습니다.

SSR 속성을 지원하는 요소의 경우 중요하지만 DOM에서 발생하는 결과를 트리거할 수 있어야 합니다. 이를 위해서는 요소 인스턴스 또는 일종의 SSR 프록시/스탠드인 및 SSR의 DOM 상태를 전달하기 위한 일부 프로토콜이 필요합니다. 아직 이 프로세스에 대한 공통 서버 측 인터페이스가 없으므로 지금은 여기서 수행할 작업이 없습니다. 웹 구성 요소 작성자와 라이브러리 유지 관리자는 React가 거기에 다리를 구축하기 전에 몇 가지 사항을 파악해야 합니다.

SSR 내 팀의 작품에서 우리는 패치에 의해 반작용과 통합 한 createElement 하고 사용하여 dangerouslySetInnerHTML . 나는 그것이 우리가 잠시 동안 있을 통합/실험의 수준이라고 생각합니다. 조만간 SSR 시스템 내에서 상호 운용성을 위한 일부 사용자 영역 프로토콜에 수렴할 수 있기를 바랍니다. 그때까지는 _deep_ SSR 없이 사용자 정의 요소 속성 및 이벤트 지원을 갖는 것이 완벽하게 안전하고 신중합니다. 요소의 태그는 오늘날과 같이 여전히 React 구성 요소의 자식으로 SSR'됩니다.

justinfagnani 에 2020년 10월 21일

👍3

id 및 className과 같은 내장 반영 속성을 제외하고는 삭제할 수 있으며 클라이언트에서만 쓸 수 있습니다.

이것이 어떻게 작동하는지 이해하도록 도와 주시겠습니까? 예를 들어 <github-icon iconname="smiley" /> 가 있다고 가정합니다. SSR이 HTML 응답에 <github-icon /> 만 포함하면 React가 수화 중에 domNode.iconname = ... 설정한다는 뜻인가요? 이 경우 React 하이드레이션이 발생하기 전에 사용자 정의 요소 구현이 로드되면 어떻게 되는지 잘 모르겠습니다. iconname 가 HTML에 없는 경우 github-icon 구현에서 렌더링할 아이콘을 어떻게 알 수 있습니까?

gaearon 에 2020년 10월 21일

아직 이 프로세스에 대한 공통 서버 측 인터페이스가 없으므로 지금은 여기서 수행할 작업이 없습니다. 웹 구성 요소 작성자와 라이브러리 유지 관리자는 React가 거기에 다리를 구축하기 전에 몇 가지 사항을 파악해야 합니다.

여기에 커뮤니티가 합의를 이루기 위해 특별히 해야 할 일이 있는지 궁금합니다. 리액트가 그것을 막고 있습니까? 이 문제가 2017년부터 공개되어 답답함을 많이 이해합니다. 한편, 3년이 지났고 아직 이러한 합의가 이루어지지 않았다고 말씀하시는 것 같습니다. 발생하기 위한 전제 조건은 무엇입니까? 단지 더 많은 실험의 문제입니까?

gaearon 에 2020년 10월 21일

@gaearon 사용자 정의 요소 구현이 React 수화 전에 로드되면 iconname 속성의 기본 값이 무엇이든 할당합니다. if _iconname_ does not exist in the HTML 은(는) 무슨 뜻인가요? HTMLElement 유형에 정의된 속성이 없으면 무시합니다. 사용자 정의 요소 정의가 로드되면 HTMLElement 유형을 확장하고 iconname 정의하고 전달되는 새 값에 반응할 수 있습니다.

yananym 에 2020년 10월 21일

👍1

나는 이것을 사용자의 관점에서 이해하려고 노력하고 있습니다. 서버에서 페이지를 렌더링하고 있습니다. 텍스트 중간에 아이콘이 있습니다. 해당 아이콘은 사용자 정의 요소로 구현됩니다. 최종 사용자가 경험해야 하는 순서는 무엇입니까?

지금까지 내 이해는 다음과 같습니다.

그들은 초기 렌더링 결과를 봅니다. 여기에는 모든 일반 마크업이 포함되지만 <github-icon> 사용자 정의 요소는 전혀 표시되지 않습니다. 아마도 빈 div와 같은 구멍이 될 것입니다. 제가 틀렸다면 지적해주세요(?). 구현이 아직 로드되지 않았습니다.
<github-icon> 사용자 정의 요소 구현이 로드되고 등록됩니다. 내가 올바르게 이해하면 이것이 "업그레이드"라는 프로세스입니다. 그러나 JS가 준비되어 있어도 HTML에 iconname 를 포함하지 않았기 때문에 여전히 아무것도 표시되지 않습니다. 따라서 렌더링할 아이콘에 대한 정보가 없습니다. 이전에 "비 내장 속성은 HTML에서 삭제할 수 있다"고 말했기 때문입니다. 따라서 사용자는 여전히 "구멍"을 봅니다.
React와 애플리케이션 코드가 로드됩니다. 수분이 발생합니다. 수화하는 동안 React는 휴리스틱에 따라 .iconname = 속성을 설정합니다. 사용자는 이제 아이콘을 볼 수 있습니다.

사용자 정의 요소 JS 구현이 먼저 로드되는 경우에 대한 올바른 분석입니까? 이것이 WC 커뮤니티에 바람직한 행동입니까?

gaearon 에 2020년 10월 21일

@gaearon 넵 이 상황에서 예상되는 일입니다.

yananym 에 2020년 10월 21일

👍2

한편 3년이 지났는데 아직 이런 공감대가 형성되지 않았다는 말씀이신 것 같은데요.

합의가 이루어지지 않았다는 말은 아닙니다. 지금 당장은 _deep_ SSR에 대해 걱정할 필요가 없으며 현재 달성할 수 있고 매우 유용한 가장 기본적인 클라이언트 측 상호 운용성을 막는 막연한 우려로 인해 걱정할 필요가 없습니다.

justinfagnani 에 2020년 10월 21일

👍3

나는 이 구별(깊은 것과 얕은 것)을 본 적이 없으므로 내가 당신을 이해했는지 확인하기 위해 다시 말하겠습니다.

"깊은" SSR은 React 구성 요소에서 작동하는 방식과 유사한 SSR을 의미한다고 생각합니다. 즉, CE를 렌더링하면 해당 CE의 논리가 로드되기 전에 표시될 수 있는 출력이 생성됩니다. 이것은 우리가 지금 지원에 대해 걱정할 필요가 없다고 말하는 것입니다. 그것은 나에게 의미가 있습니다.

"깊지 않은" SSR은 CE 태그 자체를 HTML에 넣었다고 생각합니다. 그것이 무엇을 해결하는지 걱정하지 않고. 저에게도 의미가 있습니다. 내 질문은 _이_ 흐름에 관한 것이지만 "깊은" SSR에 대한 것이 아닙니다.

특히 https://github.com/facebook/react/issues/11347#issuecomment -713230572 는 CE 로직을 다운로드한 _이미 가지고 있는 경우에도 수화될 때까지 사용자에게 아무 것도 표시할 수 없는 상황을 설명합니다. 전체 애플리케이션의 JS 클라이언트 코드가 로드되고 수화될 때까지 속성을 알 수 없습니다. 이것이 실제로 원하는 동작인지 묻고 있습니다.

제 입장에서 막연한 고민은 아닌 것 같아요. 기능 요청을 오해하고 싶지 않습니다. 따라서 정확한 의미를 지정하면 이 제안을 평가하는 데 도움이 됩니다. 예를 들어 한 가지 실질적인 우려는 내장 구성 요소 중 어느 것도 필요하지 않기 때문에 오늘날 수화 중에 생산에서 React가 실제로 속성/속성을 구별하지 않는다는 것입니다. 그러나 정말로 필요한 경우 이 특별한 경우에 추가할 수 있는 것입니다.

gaearon 에 2020년 10월 21일

@gaearon

https://github.com/facebook/react/issues/11347#issuecomment -713230572가 이 기능이 필요한 가장 좋은 예가 아닐 수도 있다고 생각합니다.

적어도 내 경험에 따르면 속성보다는 속성을 설정하는 것이 문자열, 숫자 또는 부울과 같은 단순한 유형에 필요한 전부는 아닙니다.

설명하는 경우는 iconname 를 속성으로 직접 사용하여 쉽게 달성할 수 있으며 수화를 기다리지 않고 여전히 거의 동일한 최종 렌더링 결과입니다.

NS사용자 정의 요소 구현이 로드되고 등록됩니다. 내가 올바르게 이해하면 이것이 "업그레이드"라는 프로세스입니다. 그러나 JS가 준비되어 있음에도 불구하고 HTML에 iconname을 포함하지 않았기 때문에 여전히 아무것도 표시되지 않습니다. 따라서 렌더링할 아이콘에 대한 정보가 없습니다. 이전에 "비 내장 속성은 HTML에서 삭제할 수 있다"고 말했기 때문입니다. 따라서 사용자는 여전히 "구멍"을 봅니다.

여기서 언급한 내용은 구성 요소가 구현되는 방식에 따라 "구멍"이 표시되는 이 문제를 피할 수 있습니다.

이 경우 기본 설정을 단순하게 설정하거나 슬롯을 통해 콘텐츠의 일부 또는 대부분을 수락하여 구성 요소가 업그레이드되기 전에도 콘텐츠가 표시되도록 할 수 있습니다.

이 기능은 객체, 배열, 함수 등의 속성이 있는 더 복잡한 구성 요소를 사용하는 데 가장 유용할 것이라고 생각합니다.

lit-virtualizer 가상 스크롤러 구성 요소를 예로 들어 보겠습니다.

이것이 제대로 작동하려면 items 배열과 renderItem 함수가 필요하며 선택적으로 scrollTarget 요소를 설정할 수도 있습니다. 이 모든 것은 refs를 사용하여 React에서만 설정할 수 있습니다. 지금 바로.

이와 같은 경우에는 일종의 페이지 매김 또는 지연 로딩으로 콘텐츠를 로드할 수 있으므로 SSR 케이스의 수화 단계까지 콘텐츠가 없는 것이 문제가 되지 않을 수 있습니다.

alangdm 에 2020년 10월 21일

@gaearon 사용자 정의 요소는 DOM 표준이므로 사용자 정의 요소를 사용하는 모든 사람이 동일한 방식으로 사용한다는 의미에서 "WC 커뮤니티" 자체가 없습니다. 사용자 정의 요소는 본질적으로 사람들이 구축하는 낮은 수준의 기본 요소이기 때문에 각 개발자를 위해 고유한 방식으로 통합됩니다.

즉, 시간이 지남에 따라 수많은 패턴이 등장했으며 모든 인기 있는 프레임워크(React 제외)는 이 DOM 표준에 대한 호환성을 제공하기 위해 몇 가지 솔루션을 구현합니다. https://custom-elements-everywhere.com/ 에서 볼 수 있듯이 모든 프레임워크/라이브러리(React 제외)는 다른 옵션을 선택했습니다. 이번 호에서 선택한 옵션은 옵션 1, 2, 3으로 나열됩니다. 현재 옵션 4 또는 5를 구현하는 프레임워크/라이브러리가 없으며 이러한 옵션을 구현하는 것이 바람직하지 않다고 생각합니다.

따라서 나는 React가 다른 프레임워크/라이브러리를 따르고 작동이 입증된 옵션(예: 옵션 1-3 중에서 선택)을 선택할 것을 제안합니다. 나는 React가 여기에서 옵션 4 또는 5를 선택하여 바퀴를 재발명할 필요가 없다고 생각합니다. 데이터가 없는 React 또는 DOM 표준을 기반으로 구축된 솔루션에 대해 장기적으로 유지 관리 가능한 솔루션입니다.

TimvdLippe 에 2020년 10월 21일

👍8 👎1

따라서 제거 프로세스(아래에 링크된 주석 포함)에 의해 옵션 3은 JSX에서 수행되지 않을 것이고 옵션 4와 5는 이 스레드에서 WC 사람들에 의해 바람직하지 않은 것으로 표시되었으므로 우리는 1 또는 2에 갇혀 있습니다. .

그리고 1번은 버틸 수 없는 단점이 있는 것 같아서 옵션 2번 이 하나인 것 같죠? Preact가 수행하는 방식으로 가십시오.

현재 옵션 4 또는 5를 구현하는 프레임워크/라이브러리가 없으며 이를 구현하는 것이 바람직하지 않다고 생각합니다.

( https://github.com/facebook/react/issues/11347#issuecomment-713474037의 @TimvdLippe )

이 특정 기능만을 위해 새로운 JSX 구문을 도입할 가능성은 거의 없다고 생각합니다.

( https://github.com/facebook/react/issues/11347#issuecomment-713210204의 @gaearon )

karlhorky 에 2020년 10월 21일

그것은 나에게 이해가 될 것입니다. 요약 감사합니다! 😄

TimvdLippe 에 2020년 10월 21일

적어도 내 경험에 따르면 속성보다는 속성을 설정하는 것이 문자열, 숫자 또는 부울과 같은 단순한 유형에 필요한 전부는 아닙니다. 설명하는 경우는 iconname을 속성으로 직접 사용하여 쉽게 달성할 수 있으며 수화를 기다리지 않고 여전히 거의 동일한 최종 렌더링 결과입니다.

나는 잘 따르지 않는다. 내 가상 시나리오는 https://github.com/facebook/react/issues/11347#issuecomment -713223628에 대한 응답으로 id 제외하고 서버 생성 HTML에서 속성을 전혀 내보내지 않아야 한다는 제안처럼 들렸습니다.

내가 설명한 시나리오에서 서버 생성 HTML에서 정확히 직렬화되는 것은 무엇입니까?
NS. <github-icon iconname="smiley" />
NS. 귀하가 제기한 경우, 예: <github-icon icon={{ name: "smiley" }} />
두 경우 모두 수화 중에 클라이언트에서 호출되는 DOM API

감사 해요!

gaearon 에 2020년 10월 21일

React.createElement() 를 내부에서 속성 매핑을 수행하는 사용자 정의 구현으로 대체하여 심을 생성하는 옵션으로 간주되었습니까?

사용 예:

/** <strong i="8">@jsx</strong> h */
import { h } from 'react-wc-jsx-shim';

function Demo({ items }) {
   return <my-custom-list items={items} />
}

초안 구현:

export function h(element, props, children) {
   if(typeof element === 'string' && element.includes('-')) {
      return React.createElement(Wrapper, { props, customElementName: element }, children)
   }
   return React.createElement(element, props, children);

}

function Wrapper({customElementName, props}) {
   const ref = React.useRef();
   React.useEffect(() => {
      for(const prop in props) {
         ref.current[prop] = props[prop];
      }
   });
   return React.createElement(customElementName, { ref, ...props });
}

이것이 기본 제공 기능이 아니라는 것을 알고 있지만 매우 낮은 오버헤드로 사용자 차단을 해제해야 한다고 생각합니다.

just-boris 에 2020년 10월 21일

@just-boris는 기본적으로 createElement 패치 또는 래퍼를 사용하여 앱이나 라이브러리가 현재 수행하는 작업입니다. 또한 React에서 특별한 경우의 속성 이름을 제외해야 합니다. 내 보낸 목록이 없다고 생각하므로 ['children', 'localName', 'ref', 'elementRef', 'style', 'className'] 와 같은 거부 목록을 하드 코딩합니다.

ref 기반이기 때문에 속성은 서버에서 설정되지 않습니다. 이것이 내가 우려를 모호하다고 부르는 이유입니다. React에서는 속성을 설정할 수 있는 방법이 전혀 없으므로 지금은 모두 망가졌습니다. 사용 가능한 해결 방법은 이미 클라이언트에서만 작동합니다. 서버가 아닌 클라이언트에서 속성을 설정하는 방법이 내장되어 있으면 SSR이 갑자기 수정되거나 중단되지 않습니다.

사실 저는 SSR보다 이벤트에 더 관심이 있습니다. React는 이벤트 핸들러를 추가할 방법이 없으며, 이는 기본 DOM API와의 상호 운용성에서 큰 구멍입니다.

justinfagnani 에 2020년 10월 21일

👍1

React.createElement()를 내부에서 속성 매핑을 수행하는 사용자 지정 구현으로 대체하여 shim을 만드는 옵션으로 간주되었습니까?

원래 문제에서 Rob이 언급했듯이 https://github.com/skatejs/val 을 통해 과거에 이것을 실험한 적이 있으므로 React.createElement 를 래핑하는 사용자 정의 JSX pragma를 갖는 것이 실행 가능합니다 단기 - 솔루션.

또한 특히 React에 대해 깊고 얕은 SSR이라고 하는 것을 모두 구현하는 Skate의 WIP 분기 가 있습니다. 지금까지 이 작업에서 얻은 교훈은 각 라이브러리가 자체 API 및 알고리즘에 의존하기 때문에 심층 SSR을 수행하려는 경우 모든 라이브러리에 대해 단일 JSX 래퍼를 가질 수 없다는 것입니다. (컨텍스트를 위해 Skate는 라이브러리의 핵심 사용자 정의 요소 부분과 시장에서 인기 있는 각 라이브러리를 통합하여 전반적으로 소비 및 사용을 일관되게 만들기 위해 구축된 작은 레이어를 가지고 있습니다.)

나는 더 이상 오픈 소스에서 많은 일을 하지 않으며 더 이상 트위터도 하지 않습니다.

옵션 1은 옵션 2에 대한 악마의 옹호자로 존재하는 것처럼 느껴집니다.

옵션 2는 갈 길처럼 느껴집니다. 이것은 Preact가 한 것과 비슷하므로 선례와 커뮤니티 표준의 가능성이 있습니다(어쨌든 하는 것이 환상적일 것이라고 생각합니다. JSX는 이것이 작동할 수 있음을 보여주었습니다). 또한 업그레이드하기 쉽기 때문에 React의 실용적인 움직임이기도 합니다. (옵션 1과 반대).

옵션 3은 문서상으로는 좋아 보이지만 인지 오버헤드, 언급된 오버헤드에 대한 문서화 및 SSR에 대한 알려지지 않은 사항으로 인해 논리적으로 옵션 2보다 훨씬 더 어려울 것이라고 생각합니다.

언급했듯이 원래 옵션 4를 제시했지만 반성 후 더 이상 마음에 들지 않습니다. 명시적인 props 및 events ( attrs 대신)를 지정하는 더 많은 선택으로 변경할 수 있지만, 옵션 2는 구현 세부 정보에 대한 지식이 덜 필요합니다. 그리고 그것을 채택하기 위해 변경해야 할 사람은 없습니다.

옵션 5는 핵심 문제를 완전히 무시하는 것처럼 느껴집니다.

제쳐두고, 나는 이것에 대한 관심을 보게되어 매우 기쁩니다. 그리고 여러분 모두가 잘하고 있기를 바랍니다!

treshugart 에 2020년 10월 21일

❤7

사용자 영역에 가능한 솔루션이 있다면 당분간 커뮤니티에서 통합 및 권장할 수 있습니까?

기능이 이미 인기 있고 실행 가능한 타사 모듈로 존재한다면 React 핵심 팀이 기능을 추가하도록 설득하는 것이 훨씬 쉬울 것입니다.

just-boris 에 2020년 10월 21일

사용자 영역에 가능한 솔루션이 있다면 당분간 커뮤니티에서 통합 및 권장할 수 있습니까?

나는 이것이 외부에서 [깔끔하게] 패치될 수 있는 것이라고 믿지 않습니다. 대부분의 userland 솔루션은 this 및 this 와 같은 래퍼입니다. React를 수정하지 않고는 이 접근 방식에 대한 합리적인 대안을 생각할 수 없으며 래핑은 확실히 이상적인 솔루션이 아닙니다. 😕

claviska 에 2020년 10월 21일

vuejs/vue#7582에서 Vue는 sigil을 사용하기로 선택했고 "."를 선택했습니다. 접두사로 (Glimmer의 "@"가 아님).

이에 대한 신뢰할 수 있는 설명에 대한 링크가 없지만(Vue에 더 가까운 사람이 명시적으로 확인할 수 있음) Vue가 Vue 3.0부터 Option 2로 이동한 것으로 보입니다. 즉, Preact와 유사하게 동작합니다. (맥락은 이 문제 를 참조하십시오.)

graynorton 에 2020년 10월 21일

👍2

ref 기반이기 때문에 속성은 서버에서 설정되지 않습니다. 이것이 내가 우려를 모호하다고 부르는 이유입니다. React에서는 속성을 설정할 수 있는 방법이 전혀 없으므로 지금은 모두 망가졌습니다. 사용 가능한 해결 방법은 이미 클라이언트에서만 작동합니다. 서버가 아닌 클라이언트에서 속성을 설정하는 방법이 내장되어 있으면 SSR이 갑자기 수정되거나 중단되지 않습니다.

https://github.com/facebook/react/issues/11347#issuecomment -713514984에서 특정 질문에 답변해 주시겠습니까? 우리가 서로 과거를 이야기하는 것 같은 느낌이 듭니다. 나는 단지 의도된 전체 동작을 특정한 방식으로 이해하고 싶을 뿐입니다. 언제 설정되고 어떤 경우 직렬화되는지.

gaearon 에 2020년 10월 21일

여기서 우연히 발견한 임의의 Preact+WC 개발자로서 저는 "옵션 2"가 _브레이킹 체인지_일 뿐만 아니라 _불완전한 솔루션_임을 지적하고 싶었습니다(Preact는 여전히 유효한 웹 구성 요소의 하위 집합과 선언적으로만 상호 작용할 수 있음).

휴리스틱을 현재 사용하고 있는 사람이라고 해도 장기적으로 보기에는 그다지 바람직하지 않습니다.

Preact의 휴리스틱("옵션 2")은 React(키, 자식 등) 또는 Preact( on 시작하는 모든 것)에서 특별한 의미를 갖는 속성을 설정할 수 없습니다.

즉, JSX 아래에서 렌더링한 후:

<web-component key={'key'} ongoing={true} children={[1, 2]} />

key , ongoing 및 children 속성은 web-component 의 생성된 인스턴스에서 모두 undefined (또는 기본값이 무엇이든)가 됩니다.

또한 OP와 달리 이 옵션도 브레이킹 체인지입니다. 대부분의 웹 구성 요소(예: lit-element )는 순수 HTML과 함께 사용하기 위해 속성을 통해 직렬화된 풍부한 데이터를 전달할 수 있는 기능을 제공합니다. 이러한 구성 요소는 다음과 같이 React에서 렌더링될 수 있습니다.

<web-component richdata={JSON.stringify(something)} />

"옵션 2"를 선택하면 중단됩니다. 웹 구성 요소의 이러한 사용이 React에서 얼마나 일반적인지 확실하지 않지만 그렇게 하는 일부 코드 기반이 분명히 있습니다. refs보다 덜 효율적이지만 간결합니다.

마지막으로 Web Component의 작성자는 동일한 이름의 속성과 속성에 미묘하게 다른 의미를 자유롭게 추가할 수 있습니다. 예를 들어 기본 input 요소의 동작을 모방하는 웹 구성 요소가 있습니다. value 속성을 초기 값으로 처리하고 value 속성의 변경 사항만 관찰합니다. 이러한 구성 요소는 경험적 접근 방식으로 jsx를 통해 완전히 상호 작용할 수 없으며 도입된 경우 미묘한 손상을 경험할 수도 있습니다.

brainlessbadger 에 2020년 10월 21일

👍2

이 특정 기능만을 위해 새로운 JSX 구문을 도입할 가능성은 거의 없다고 생각합니다.

네임스페이스를 사용하는 것은 어떻습니까? https://github.com/facebook/jsx/issues/66 은 key 및 ref 에 대한 react 네임스페이스 추가를 제안합니다. 같은 맥락에서 react-dom 것이 DOM 속성을 식별하는 데 사용할 수 있는 괜찮은 네임스페이스가 될까요? OP의 옵션 3 예를 사용하면 다음과 같습니다.

<custom-img react-dom:src="corgi.jpg" react-dom:hiResSrc="[email protected]" width="100%">

그것은 가장 인체 공학적이지 않습니다. dom 있으면 더 좋겠지만 React가 react 시작하지 않는 네임스페이스를 만들고 싶어하는지 확실하지 않습니다. 또한 속성으로 설정하는 것이 덜 일반적인 경우라는 아이디어가 있다면 이것에 대한 잘못된 인체 공학은 세상의 끝이 아닙니다. SSR과의 패리티를 제공하기 때문에 속성을 사용하는 것이 더 좋습니다. 속성으로 설정하는 것은 속성에 문제가 있는 경우(예: 개체를 전달하거나 속성이 지원하지 않는 속성에 대한 경우)용이며, 어쨌든 속성에 SSR을 적용할 수 없고 수화해야 하는 문제가 있는 속성에 대한 것입니다. JS를 통해

effulgentsia 에 2020년 10월 21일

👍1

_불완전한 해결책_
(Preact는 여전히 유효한 웹 구성 요소의 하위 집합과 선언적으로만 상호 작용할 수 있습니다.)

@brainlessbadger 이 하위 집합이 실제로 무엇인지 포함하도록 위의 의견을 편집할 수도 있습니까? 예. 어떤 웹 구성 요소/사용자 정의 요소가 영향을 받습니까(예제 포함)? 그리고 정확히 어떻게 영향을 받습니까?

karlhorky 에 2020년 10월 22일

@karlhorky 설명을 추가했습니다. 쓸데없이 모호해서 죄송합니다.

brainlessbadger 에 2020년 10월 22일

❤1

웹 구성 요소 이벤트 관련. 이벤트 이름 충돌로 인해 향후 차단을 방지하는 방법에 대한 합의가 아직 있습니까?

다음과 같이 HTMLElement에 새 속성을 추가할 수 있기 때문에 속성 및 속성에도 문제가 있습니다. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes 새로 추가된 항목도 있으므로 여전히 새로운 항목이 추가되고 있습니다.

엄밀히 말하면 사용자 정의 속성이나 사용자 정의 이벤트의 이름에 - 를 사용해야 한다고 생각합니다.

다른 모든 것은 해당 구성 요소가 향후 사양에서 멋진 이름을 사용하지 못하도록 차단하는 위험을 평가하는 절충안입니다.

이벤트는 해당 구성 요소가 호환되지 않는 동작을 할 위험이 없기 때문에 저를 더욱 긴장하게 만듭니다. 새 이벤트가 버블링되면 해당 트리 경로에 있는 모든 기존 웹 구성 요소가 트리거됩니다.

사용자 정의 속성 및 이벤트가 이름에 - 를 사용해야 하는 경우 사용할 항목을 결정하기 위한 경험적 방법으로 사용할 수 있습니다. 그런 다음 내장된 특수한 경우를 사용합니다. 이것이 우리가 처음에 사용자 정의 요소인지 여부를 이미 아는 방법입니다.

그런 다음 속성을 편의로 사용하여 더 좋은 약식을 제공할 수 있습니다. 적어도 그것들은 내장 속성을 가리고 미래 속성과 충돌하지 않을 수 있습니다.

sebmarkbage 에 2020년 10월 22일

👎1

엄밀히 말하면 사용자 정의 속성이나 사용자 정의 이벤트의 이름으로 -를 사용해야 한다고 생각합니다.

사용자 정의 요소 사양에는 이러한 제한 사항이 포함되어 있지 않으므로 React에서 적용하면 상호 운용성에 상당한 영향을 미칩니다.

사용자 정의 요소 작성자는 프레임워크의 임의 요구 사항을 구독할 것으로 기대해서는 안 됩니다. 다양한 의견과 관습으로 모든 프레임워크가 이 작업을 수행한다고 상상해 보십시오. 이것은 웹 구성 요소를 사용하는 목적을 무효화합니다. 😕

이상적으로는 프레임워크가 표준을 수용하도록 조정되어야 합니다.

claviska 에 2020년 10월 23일

👍4 ❤1

물론. setAttribute() 및 dispatchEvent() 는 처음부터 임의의 이름을 허용한 웹 구성 요소가 아닌 특정 API입니다. 모든 요소는 모든 속성을 가질 수 있고 모든 이벤트를 발생시킬 수 있습니다. 이는 DOM의 기본 정보일 뿐입니다.

justinfagnani 에 2020년 10월 23일

👍4

data- 네임스페이스가 추가된 이유가 있습니다. 기술적으로 할 수 있는 것과 모범 사례 사이에는 차이가 있습니다. 기술적으로 프로토타입을 패치할 수도 있지만 포함/포함 상황이 발생합니다.

React만이 이것을 추가하는 것이 아니라 커뮤니티가 미래의 네임스페이스를 보호하는 데 도움이 되도록 이 규칙으로 전환하는 것을 제안하지 않습니다. 다만 이 문제가 심각하게 받아들여지지 않는 것이 안타까울 뿐입니다. 그러나 아마도 웹은 새로운 API에 어색한 이름만 추가할 운명입니다.

sebmarkbage 에 2020년 10월 23일

👍7 😕4 👎1

나는 SSR에서 내장되지 않은 것을 제외한다는 아이디어를 좋아하고 선언적 그림자 DOM을 사용하면 실제 콘텐츠가 내부에서 확장될 수 있기 때문에 수화 중에 속성을 선호합니다.

구체적으로는 속성을 사용하고 AMP 런타임이 이미 로드되었다고 가정할 수 있기 때문에 사람들이 SSR + AMP와 함께 사용하는 현재 접근 방식에 문제를 일으킬 것이라고 생각합니다.

sebmarkbage 에 2020년 10월 23일

옵션 3에서 문이 닫히지 않았다고 가정하면 위의 단점에 나열되지 않은 옵션 2에 비해 상당한 이점이 있습니다. -- 옵션 2에서 발견한 문제는 웹 구성 요소 라이브러리가 비동기식 으로 로드되는 경우 preact가 그렇지 않을 수 있다는 것입니다. 알 수 없는 요소의 경우 "속성"이 속성이 될 것임을 알고 있습니다. unknown 요소에 있는 속성을 찾지 못하므로 기본적으로 속성이 사용됩니다. 해결 방법은 종속 웹 구성 요소 라이브러리가 로드될 때까지 해당 구성 요소를 렌더링하지 않는 것입니다. 이는 매우 우아하지 않거나 성능면에서 이상적이지 않습니다. 우리 그룹은 node.js가 아닌 asp.net을 사용하기 때문에 실제로 SSR을 탐색한 적이 없으므로 아래 관찰은 추측입니다.

React 팀의 입장에서는 SSR까지 다른 프레임워크가 지원하는 것 이상으로 제안하는 것은 좋은 제스처라고 생각합니다. 사용자가 더 좋습니다.

뻔한 말인지 아닌지는 모르겠지만 일부 속성의 경우 JSON 문자열을 통해 속성의 초기 값을 설정하는 것이 편리하다는 웹 구성 요소에 약간의 합의 가 있다고 생각 합니다 . 작은따옴표로 묶습니다.

AMP는 다른 규칙을 사용합니다. -- 이를 수행하기 위해 스크립트 type=application.json 을 사용합니다. 이는 합리적인(그러나 장황한) 대안입니다.

그러나 속성 접근 방식을 고수합니다.

그런 다음 웹 구성 요소 라이브러리는 속성을 구문 분석하거나 속성을 통해 값을 전달할 수 있습니다.

따라서 수화 지연을 방지하려면 다음을 설정하는 것이 편리합니다.

<github-icon icon='{"name":"smiley"}'></github-icon>

SSR 중. 그러면 github-icon은 즉시 그 일을 할 수 있고 내부적으로 속성의 JSON.parse를 수행하고 React가 (더 완전한?) 객체 값을 전달할 때까지 기다릴 필요가 없습니다.

이제 우리는 까다로운 상황에 처했습니다. 서버에서 렌더링하는 경우 "아이콘"이 속성으로 처리되기를 원하지만 값을 개체로 전달할 수 있기를 원합니다. 이상적으로는 SSR 메커니즘이 속성으로 문자열화할 것입니다. 클라이언트에서 우리는 객체를 직접 전달할 수 있기를 원하며 문자열화 및 구문 분석의 오버헤드를 거치지 않기를 원합니다.

물론 일부 속성은 문자열화/파싱을 수행할 수 없는 개체이므로 이는 적용되지 않으며 해당 속성은 수화가 완료될 때까지 기다려야 합니다.

모든 속성과 속성이 React 팀이 선호하는 명명 규칙(아마도)을 따랐다면 -- 모든 속성에 대시가 있고 모든 속성이 camelCase를 사용하는 복합 이름이었다면 대시가 있으면 속성과 속성을 구별하는 데 도움이 될 수 있습니다.

<github-icon my-icon={myStringifiedProperty} myIcon={myObjectProperty}></github-icon>

문제는 위의 구문에서 클라이언트와 서버에서 수행할 작업을 나타내지 않으며 이상적으로는 둘 다에 대해 하나의 바인딩을 사용할 수 있고 React는 어느 것을 사용할지 알아낼 만큼 충분히 똑똑할 것입니다.

React는 속성/속성 키가 카멜 케이스인 경우 항상 클라이언트 측에서 객체로 전달하고 SSR 중에 설정된 경우 객체의 JSON 문자열 직렬화를 전달한다고 가정할 수 있습니다. 마찬가지로, 키의 대시는 (안전하게, 제 생각에) 그것이 속성이라고 가정하고 값의 .toString()을 전달할 수 있습니다. 그러나 나는 이것이 너무 많은 것을 가정한다고 생각합니다. 그리고 HTMLElement를 확장하는 웹 컴포넌트에 속성을 적용하면 유효한 HTML로 간주되는 단일 단어 속성 및 속성을 지원하지 않는 것은 너무 제한적입니다. 나는 W3C가 미래에 사용할 수 있는 "예약된" 속성 이름 목록을 발행하는 데 찬성합니다. 이는 JS의 예약된 키워드와 유사하며, 예약된 속성 이름을 부적절하게 사용하는 경우 개발자에게 경고하는 방법을 찾는 프레임워크를 찾는 것입니다.

그러나 옵션 3이 가장 좋은 방법이라고 생각합니다. 그러나 더 나은 사용자 경험을 위해 @gaearon이 제안한 대로 향상될 수 있다면 좋을 것입니다.

내 제안은 다음과 같습니다.

<github-icon icon={myDynamicIcon}/>

속성(toString())을 의미합니다.

<github-icon icon:={myDynamicIcon}/>

의미 -- SSR 동안 무시하지만 클라이언트에서 개체 속성에 바인딩합니다(수화 후).

이제 시나리오(일부?)는 어떻습니까? React 팀이 해결하는 데 관심이 있습니까? 내 첫 번째 생각은 두 개의 콜론과 같은 다른 기호였습니다.

<github-icon icon::={myDynamicIcon}/> //Not my final suggestion!

즉, SSR 동안 JSON.stringify 속성을 렌더링된 HTML에서 속성으로 설정하고 속성이 수화 후 변경 사항에 바인딩될 때 클라이언트에서 개체로 전달합니다.

이것은 복합 이름으로 무엇을 해야 하는지에 대한 까다로운 상황을 남깁니다. 즉, 다음을 설정하면:

<github-icon iconProps::={myDynamicIconProp}/>  //Not my final suggestion!

속성 이름 iconProps에 대한 해당 속성이 icon-props여야 한다는 것은 과거에 논란의 여지가 없었습니다.

아마도 이러한 웹 구성 요소 중 일부가 변경 없이 플랫폼에 내장될 수 있다는 망령 때문에 이것은 더 논란이 되었을 것입니다. 속성에는 대시가 포함될 수 없습니다(그러나 속성은 camelCase일 수 있음). 내가 아는 한 JSON 역직렬화를 통해 복잡한 개체를 전달할 수 있는 기본 요소는 아직 없지만 나중에 필요할 경우 놀라지 않을 것입니다. 그렇다면 React는 대시를 언제 삽입할지 여부를 어떻게 알 수 있을까요?

내가 생각해낼 수 있는 유일한 (추한?) 제안은 다음과 같습니다.

<github-icon icon-props:iconProps={myDynamicIconProp}/>

즉, 서버에서는 직렬화 후 속성 icon-props를 사용하고 클라이언트에서는 속성 iconProps를 사용하여 개체를 직접 전달합니다.

하이브리드 속성/속성 쌍을 허용하는 더 자세한 표기법의 또 다른 잠재적 이점은 다음과 같습니다. 특히 다음과 같은 경우 해당 속성보다 기본 요소의 속성을 반복적으로 설정하는 것이 조금 더 빠를 수 있습니다. 문자열이 아닌 속성. 그렇다면 React는 현재 서버의 속성과 클라이언트의 속성을 사용합니까? 그렇지 않다면 이 표기법으로 해결할 수 있는 명명 번역의 어려움과 같은 문제 때문입니까?

bahrus 에 2020년 10월 26일

@bahrus 단순화 할 수 있다고 생각합니다.

<my-element attr='using-quotes' property={thisIsAnObject} />

eavichay 에 2020년 11월 10일

구체적인 예를 들어 문제를 설명하는 것이 가장 좋을 것 같습니다.

HTML Form 요소에는 여러 속성이 있습니다. "복합 이름"이 있는 이름은 모두 일관된 이름 지정 패턴을 따르는 것 같지 않습니다. 일반적으로 모두 소문자를 사용하고 구분 기호가 없지만 대시 구분 기호가 있는 경우도 있습니다. - "갱신하다".

해당 JS 속성 이름은 acceptCharset, noValidate와 같은 멋진 범용 패턴에도 맞지 않습니다. noValidate 속성/novalidate 속성은 부울이므로 클라이언트에서 myForm.noValidate = true와 반대로 myForm.setAttribute('novalidate', '')를 수행하는 것은 낭비(상상)입니다.

그러나 서버에서 myForm.noValidate = true로 설정하는 것은 의미가 없습니다. DOM의 문자열 표현을 보내고 싶기 때문에 속성을 사용해야 하기 때문입니다.

<form novalidate={shouldNotValidate}>

사실, React/JSX가 boolean 속성을 조건부 로 고정된 정적 조회 테이블 에 의존

개발자가 성능을 희생하지 않고 서버(속성을 통해)와 클라이언트(속성을 통해)를 완전히 제어할 수 있도록 이러한 모든 시나리오를 어떻게 나타낼 수 있습니까? novalidate와 같은 부울의 경우 다음을 제안합니다.

<form novalidate:noValidate?={shouldNotValidate}/>

React가 DOM을 완벽하게 지원한다면, 지저분하지만 가능한 한 성능이 좋은 방식으로, 네이밍 패턴에서 그다지 일관성이 없을 수도 있는 사용자 지정 요소를 지원하는 데 큰 도움이 될 것이라고 생각합니다.

서버에서 JSON.stringify를 통해 속성에 객체 속성을 선택적으로 직렬화하는 지원을 추가하면 React 및 웹 구성 요소에 추가적인 큰 윈-윈이 될 것 같습니다.

아니면 내가 뭔가를 놓치고 있습니까? ( @eavichay , 귀하의 예를 따르지 않고 이러한 시나리오를 가장 잘 표현하는 방법을 제안하시겠습니까?)

bahrus 에 2020년 11월 11일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

React: RFC: React 18의 사용자 정의 요소 속성/속성 계획

목차/요약

배경

제안

옵션 1: 속성만 설정

장점

이해/구현 용이

미래 전역 속성과의 충돌 방지

사용자 정의 요소 "업그레이드" 활용

다른 React 구성 요소처럼 취급되는 사용자 정의 요소

단점

아마도 브레이킹 체인지

속성을 설정하려면 참조가 필요합니다.

서버 측 렌더링이 어떻게 작동하는지 명확하지 않음

옵션 2: 가능한 경우 속성

장점

핵심 변경 사항

단점

개발자는 휴리스틱을 이해해야 합니다.

속성으로 폴백하면 미래 전역과 충돌할 수 있습니다.

옵션 3: 인장으로 속성 구별하기

장점

개발자가 선택할 수 있는 핵심 변경 사항

다른 라이브러리가 속성/속성을 처리하는 방식과 유사

시스템이 명시적입니다.

단점

새로운 구문입니다

서버 측 렌더링이 어떻게 작동하는지 명확하지 않음

옵션 4: 속성 개체 추가

장점

시스템이 명시적입니다.

확장 구문은 이벤트 처리 문제도 해결할 수 있습니다.

단점

새로운 구문입니다

획기적인 변화일 수 있습니다

이전 제안보다 더 큰 변화일 수 있습니다.

옵션 5: 맞춤 요소를 사용하기 위한 API

장점

시스템이 명시적입니다.

핵심 변경 사항

반응에 관용적

단점

복잡한 구성 요소의 경우 많은 작업이 필요할 수 있습니다.

번들 크기가 커질 수 있음

구성은 구성 요소와 보조를 맞춰야 합니다.

가장 유용한 댓글

모든 129 댓글

옵션 2에 대한 의견

옵션 3에 대한 의견

관련 문제