나는 이것을 좋아한다. 번들 크기와 "클래스" 소품을 줄이는 것은 매우 환영할 일입니다.

훌륭한 일!

🙂

관심 양식 라이브러리 작성자! 🤣

엄청난!

className → 수업은 환상적입니다

다른 모든 사람들은 어떻습니까? clipPath , htmlFor , tabIndex 등을 계속 하는 것이 이상해 보입니다.

class 도입은 도서관을 초심자에게 보다 친숙하게 만드는 중요한 돌파구입니다. 축하합니다.

이것은 굉장합니다. class 로의 이동이 실제로 소품과 어떻게 작동하는지 궁금합니다.

({ class }) => <div class={class} /> 이 처음에 예약된 키워드 문제를 나타내는 것 같습니까?

반가운 소식입니다 @gaearon님 감사합니다!

className 변경 사항을 제외하고 이 모든 점을 좋아합니다. 다른 지점이 추구하는 목표(DOM API와 일치)와 완전히 모순되는 것 같습니다. React는 HTML 속성이 아닌 DOM 속성에 바인딩됩니다(이것은 첫 번째 요점에서도 명확히 설명됨). DOM 요소 속성의 이름은 className 가 아니라 class 입니다. 그렇다면 React에서 이름이 class 인 이유는 무엇입니까?

환상적이야! 번들 크기 축소에 대한 목표가 있습니까?

👏

다른 모든 사람들은 어떻습니까? 여전히 clipPath, htmlFor, tabIndex 등을 수행하는 것이 이상해 보입니다.

나는 토론의 여지가 있지만 이러한 변경 사항은 가치가 없다고 주장합니다( for 제외).

이벤트 시스템을 재작성한 것이 이 점에서 가장 흥미로운 부분이라고 생각합니다. 번들 크기를 줄이고 커뮤니티 기여를 쉽게 할 수 있는 상당한 기회가 있습니다.

해보자!

JSX 2.0 을 동시에 출시하는 작업도 해볼 가치가 있는지 궁금합니다. 어쨌든 사람들은 몇 가지를 다시 배워야 합니다. 몇 가지를 두 번 반복하는 것보다 한 번에 많은 것을 다시 배워야 하지 않을까요? 이 글을 읽으면서 문득 떠오른 생각.

나는 className 변경을 제외하고 이러한 모든 점을 좋아합니다. 다른 지점이 추구하는 목표(DOM API와 일치)와 완전히 모순되는 것 같습니다. React는 HTML 속성이 아닌 DOM 속성에 바인딩됩니다(이것은 첫 번째 요점에서도 명확히 설명됨).

그러나 알려지지 않은 키/값 쌍을 전달하면 React 16 이후 속성으로 처리됩니다. 따라서 우리는 이미 일관성이 없습니다. 또한 내 의견은 React가 value 속성을 설정 하기를 기대하는 사용자가 잘못되었다는 것입니다. React API가 API에서 속성 이름을 사용하는지 속성 이름을 사용하는지 여부는 완전히 직교합니다.

나는 수년 동안 이 주장에 대해 당신의 입장을 변호해 왔지만 지금은 이것이 가치가 없는 마찰이라고 생각합니다. 당신은 그것에서 아무것도 얻을 수 없습니다. 사람들이 class 를 사용하게 하는 것은 구조화 및 마이그레이션 비용과 함께 작동하지 않는다는 점을 제외하고는 부정적인 영향이 없습니다. 모두가 React를 배울 때 그것에 대해 불평합니다. 나는 이 경우에 사람들이 기대하는 바를 행하는 것이 현학적인 것보다 더 중요하다고 생각합니다. 어쨌든 다른 DOM을 변경하고 있으므로 함께 일괄 처리해 보겠습니다.

React Fire가 빠르게 타오르는 한.... 👍

이러한 변화는 모두 환상적입니다. 나는 이것과 react-testing-library 에 대한 의미에 대해 매우 흥분됩니다. 특히, 이벤트가 반응 루트에 바인딩되어(또는 최신 환경에서 더 이상 필요하지 않을 수 있으므로 이벤트 위임을 완전히 삭제할 수도 있습니까?), 잠재적으로 합성 이벤트를 제거/재작성하고, onChange -> onInput 는 react-testing-library 의 구현과 도구 사용 경험을 심각하게 개선할 것입니다.

구현되는 동안 이에 대한 피드백을 제공하고 싶습니다.

현대 환경에서는 더 이상 필요하지 않을 수 있으므로 이벤트 위임을 완전히 삭제할 수도 있습니다.

우리는 이것을 고려했지만 이것이 지나친 단순화일 수 있다고 생각합니다. 이벤트 위임을 사용하면 초기 렌더에서 모든 노드에 대해 많은 리스너를 설정하지 않아도 됩니다. 그리고 업데이트 시 교환합니다. 이러한 측면을 무시해서는 안됩니다. 그러나 거기에서 더 많은 벤치마킹이 수행될 가능성이 있습니다.

@tannerlinsley ({ class: className }) => <div class={className} /> 불행히도 이것은 jsx 2.0 객체 약식 표기법( <div class /> )을 죽일 것입니다. 하지만 그렇게 될 것입니다 ...

class 가 마침내 문자열 옆에 객체와 배열 btw를 취할 수 있다면 정말 좋을 것입니다.

번들 크기 축소에 대한 목표가 있습니까?

React DOM의 1/3을 삭제하는 것이 좋습니다. 우리는 볼 것이다. 섣불리 말씀드리기는 어렵지만 최선을 다하겠습니다.

와우, 이것은 사람들이 React 단점에 대해 질문할 때 언급하는 거의 모든 디자인 결정을 열거한 것입니다.

이것이 가고 있는 방향을 사랑하십시오.

className 를 사용하고 여러 버전의 React를 지원하려는 라이브러리의 업그레이드 경로는 무엇입니까?

@gaearon 오늘은 "props는 HTML 속성이 아닌 DOM 속성"이라고 말하는 것이 좋을 것입니다. 이제 "className을 제외하고 HTML 이름입니다"가 될 것입니다. 나는 또한 SVG를 복사/붙여넣기할 수 있고, React의 속성과 일치시키기 위해 10분 동안 속성을 어지럽히지 않고 싶습니다.

htmlFor 는 어떻습니까?

className -> class 전환은 아마도 장기간에 걸쳐 매우 신중하게 이루어져야 할 것 같습니다. 거의 모든 구성 요소가 변경되어야 하므로 생태계에 많은 문제를 일으킬 것입니다. 이것은 코드를 "소유"하고 codemod가 있는 경우 대부분 괜찮지만 타사 라이브러리에 의존하는 경우 대부분 유지 관리자의 자비에 따릅니다.

나머지 변경 사항은 생태계 관점에서 볼 때 상대적으로 위험이 낮아 보이지만 className 를 제거하는 것은 실제로 많은 고통을 야기합니다. 그건 별도의 호로 나누어서 나머지 🔥 변경 사항과 다른 일정으로 공개하는 것이 가능해야 할 것 같습니다.

@felixfbecker님 말씀에 동의합니다.
모든 것이 훌륭하게 들리고 개발자와 사용자 모두에게 품질이 향상되지만 className은 변경됩니다.

모든 속성을 분해할 수는 있지만 클래스가 키워드이기 때문에 className을 사용해야 하는 것보다 새 사용자에게 더 많은 혼란을 일으키고 설명하기가 더 어렵습니다(색이 다르게 지정되어 실수가 발생했을 때 명확하게 볼 수 있음). . 해체에서 클래스를 해결하려면 rest 속성을 사용해야 할 때까지만 작동하는 특정 속성을 읽는 완전히 다른 방법이나 새로운 구문을 도입해야 합니다.
4명의 캐릭터를 구하는 것만으로도 많은 문제가 발생합니다.

@felixfbecker JSX 에서는 class / for , JS 버전에서는 className / htmlFor 수 있습니까?

<label class="foo" for="bar">..</label>

될 것이다

React.createElement('label', {className: 'foo', htmlFor: 'bar'}, '..')

좋은 계획! 반가워요! 👏👏👏

이것은 굉장합니다. 나는 새로운 것을 파고들기를 기다릴 수 없습니다.

이벤트 시스템을 대폭 간소화합니다(#4751).

이제 React는 ReactDOM 정의를 확장하지 않고 사용자 정의 요소에 핸들러를 위임할 수 없습니다. https://github.com/facebook/react/issues/9242

이는 React가 <x-component onMyEvent={ev => {...}} /> 와 같은 사용자 정의 요소에 대해 사용자 정의 핸들러를 설정할 수 없음을 의미합니다.

@gaearon
이에 대한 계획이 있으신가요?

이 모든 변경 사항이 훌륭하지만 가장 큰 메타 변경 사항은 제 생각에 크기 감소입니다. React는 평균 DX를 가지고 있지만 평균 네트워크, 특히 모바일에서 다운로드하고 구문 분석하는 것이 문제가 될 정도로 뚱뚱합니다.

우리는 모든 것을 가질 수 있습니다!

이벤트 위임을 다시 작성하면 #1254 수정의 문을 엽니다. 일부 이벤트는 연결된 노드의 성능을 저하시킵니다(React의 경우 전체 앱을 의미함).

또한 장기적으로 합성 dataSet 소품을 고려한 적이 있습니까? (data-* 때문에) 허용되는 HTML props를 입력할 수 없으면 props를 DOM 노드로 전달할 때 수많은 버그가 발생합니다. 현재 유형이 지정된 React 구성 요소는 props의 정확한 유형과 데이터 속성 허용 중에서 선택해야 합니다.

나는 신이 난다

@ryanflorence 약간 오프탑이지만 (내가 아는 한) 아무도 HTML을 매핑하는 사소한 변경으로 React로의 마이그레이션을 쉽게 하기 위해 html/css/svg -> jsx 트랜스포머를 만들 생각을 하지 않았다는 것은 다소 슬픈 일입니다. React props에 대한 속성. 대부분 찾기 및 교체를 수행하는 데 많은 시간이 낭비되었습니다.:(

동일한 문제(및 주석)에서 다음을 보는 것은 매우 이상합니다.

우리의 목표는 React가 DOM 작동 방식에 더 잘 맞도록 만드는 것입니다.
클래스명 → 클래스
여전히 clipPath, htmlFor, tabIndex 등을 수행하는 것이 이상해 보입니다.

이 모든 것이 DOM API의 직접적인 대응물일 때

그리고 이 인수는 소집을 통과하지 않습니다.

나는 수년 동안 이 주장에 대해 당신의 입장을 변호해 왔지만 지금은 이것이 가치가 없는 마찰이라고 생각합니다. 당신은 그것에서 아무것도 얻을 수 없습니다. 클래스를 사용하게 하는 것 외에는 부정적인 영향이 없습니다.

React는 항상 JS 위에 있는 매우 얇은 레이어였습니다. 따라서 JSX의 꺾쇠 괄호를 제외한 다른 모든 것은 JS였고 _그리고_ DOM API와 직접적으로 관련된 DOM API( className , clipPath , htmlFor , tabIndex 등 등)에 대한 직접적인 대응이 있었습니다.

class 도입 결정으로 React는 더 이상 얇은 계층이 되지 않고( class 는 JS에서 예약어임) DOM API와 더 많이 호환된다는 선언된 목표에서 벗어났습니다.

DOM과 일치하지 _및_ className -> class 를 마이그레이션하여 DOM과 일치하지 않기 때문에 "onChange에서 onInput으로 마이그레이션"을 모두 원한다는 사실은 특히 충격적입니다.

또한 사람들이 다른 부품에 대한 변경을 요구할 것이기 때문에(그리고 이미 요구하고 있기 때문에) 웜의 전체 캔을 엽니다. 주석에서: data-* dataset 를 사용하는 이유는 무엇입니까? data-* 가 유효한 JS가 아니기 때문에( class 와 비슷함) DOM API 와 일관되기 때문일까요? htmlFor 를 바꾸지 않겠습니까? for 는 예약어이고 htmlFor 는 DOM API에 있기 때문에? 등 등 등

그러나 알려지지 않은 키/값 쌍을 전달하면 React 16 이후 속성으로 처리됩니다. 따라서 우리는 이미 일관성이 없습니다.

@gaearon 은 React가 CustomElements Everywhere 상호 운용성 테스트에서 나쁜 점수를 받은 유일한 라이브러리인 이유이기도 합니다. https://custom-elements-everywhere.com/
그리고 변경을 요청하는 많은 문제가 있습니다: https://github.com/facebook/react/issues/11347 , https://github.com/facebook/react/issues/7249 , https://github.com/facebook /반응/문제/9230

이것은 문제가 되지 않을 수도 있지만 React Fire와 React Fiber의 유사성은 영어가 모국어가 아닌 사람들에게 혼동을 줄까요? 나는 종종 Newark Penn Station과 New York Penn Station이 여기 NYC에서 같은 기차 노선에 있다는 것이 관광객들에게 특히 잔인한 농담이라고 생각했습니다.

정말 우려되는 일이라면 React Flame이라고 하고 여전히 불 🔥 이모티콘을 유지할 수 있습니다.

이벤트 위임을 다시 작성하면 #1254 수정의 문을 엽니다. 일부 이벤트는 연결된 노드의 성능을 저하시킵니다(React의 경우 전체 앱을 의미함).

어떤 형태로든 #1254를 수정하는 것은 확실히 내가 보고 싶은 것입니다.

또한 장기적으로 합성 dataSet 소품을 고려한 적이 있습니까?

더 큰 표면이 있기 때문에 지금은 이와 같은 일을 하고 싶지 않습니다. DOM을 위한 더 풍부한 인터페이스( ariaSet , dataSet , classList )는 이해가 되지만 더 높은 수준의 라이브러리와 비교하여 React DOM에 얼마나 투자하고 싶은지는 분명하지 않습니다. 더 풍부한 DOM API를 제공합니다. 이러한 변경 사항은 외형적이지만 표면적이 높기 때문에 보류하겠습니다.

리액트 블레이징 🔥

@ryanflorence 약간 오프탑이지만 (내가 아는 한) 아무도 HTML을 매핑하는 사소한 변경으로 React로의 마이그레이션을 쉽게 하기 위해 html/css/svg -> jsx 트랜스포머를 만들 생각을 하지 않았다는 것은 다소 슬픈 일입니다. React props에 대한 속성. 대부분 찾기 및 교체를 수행하는 데 많은 시간이 낭비되었습니다.:(

@jxub
https://transform.now.sh/html-to-jsx/

새로운 변경 사항에 매우 흥분하여 Facebook의 여러분은 이 마이그레이션으로 역사를 만들고 있습니다. 50k 구성 요소가 React Fire로 마이그레이션됩니까?
테스트 스위트는 매우 엄격해야 합니다. <3

React Fire와 React Fiber의 유사성은 영어가 모국어가 아닌 사람들에게 혼동을 줄까요?

난청이 있는 사람들(또는 단어 차별에 영향을 미치는 다른 조건을 가진 사람들)에게도 해당될 수 있습니다.

@gaearon 공유해주셔서 감사합니다.

Babel 및 Typescript로 코드를 컴파일할 때 발생하는 공백 및 줄 바꿈 문제를 해결하는 JSX 2.0 릴리스를 보고 싶습니다.

다른 문제가 열렸고 기여하려고 했지만 React 팀이 JSX와 관련된 모든 것을 검토해야 하기 때문에 연락이 끊겼습니다.

이 문제는 어쨌든 dom과 관련이 있습니다. 왜냐하면 우리가 jsx를 js로 변환하는 방식이 w3c가 말하는 것을 허용하지 않기 때문입니다.

이것이 문제입니다 https://github.com/facebook/jsx/issues/19

내 의견은 맨 마지막에 있습니다.

className 괜찮습니다. 그것이 무엇인지 보자. 부상에 모욕을 추가하지 마십시오.

누군가 이것이 기존 핸들러에 어떤 영향을 미치는지 설명해 주시겠습니까?

값 속성에 입력 값 반영 중지

React는 여전히 핸들러에서 정확한 event.target.value 업데이트로 제어된 입력을 가질 수 있습니까? 아니면 이것이 ref 및 DOM 노드에서 값을 읽는 데에만 영향을 줍니까?

@nickmccurdy 브라우저 devtools에 표시되는 내용에 영향을 줍니다.

@tomdale 리액트 엠버 🔥

멋진! React 17의 전체 변경 사항 목록을 보고 싶습니다.
나는 그것이 ReactJS의 새로운 시대가 될 것이라고 믿습니다. 🔥⚛️

@tomdale 흠: 원사, 섬유, 직물; 다른 의류 관련 용어를 사용할 수 있습니까? 😆

그러나 알려지지 않은 키/값 쌍을 전달하면 React 16 이후 속성으로 처리됩니다. 따라서 우리는 이미 일관성이 없습니다.

@gaearon 은 React가 CustomElements Everywhere 상호 운용성 테스트에서 나쁜 점수를 받은 유일한 라이브러리인 이유이기도 합니다. https://custom-elements-everywhere.com/

아니요, 그게 이유가 아닙니다(사용자 정의 요소와 일반 요소는 완전히 별개의 코드 경로입니다). 그 이유는 우리가 이미 이전 동작을 가지고 있었고 새로운 동작이 견고하지 않는 한 이전 버전과의 호환성을 깨고 싶지 않았기 때문입니다. 이 우산의 일부로 더 나은 사용자 지정 요소 상호 운용성을 다루는 것이 합리적이라고 생각합니다.

React Fire와 React Fiber의 유사성은 영어가 모국어가 아닌 사람들에게 혼동을 줄까요?

둘 다 내부 코드명이며 프로젝트가 완료되면 실제로 의미가 없습니다. React Fire는 React DOM을 더 좋게 만들기 위한 노력일 뿐이며 프로덕션 준비가 되면 React DOM일 것입니다.

React는 여전히 핸들러에서 정확한 event.target.value 업데이트로 제어된 입력을 가질 수 있습니까? 아니면 이것이 ref 및 DOM 노드에서 값을 읽는 데에만 영향을 줍니까?

예, event.target.value 가 속성 이기 때문입니다. 속성 업데이트 중지에 대해 이야기하고 있습니다. 다른 인기 있는 라이브러리에는 없는(AFAIK) 수많은 문제가 발생합니다. 값에 대한 CSS 선택기에 의존하지 않는 한 코드에 영향을 미치지 않아야 합니다(어쨌든 나쁠 수 있음).

멋진! React 17의 전체 변경 사항 목록을 보고 싶습니다.

17시까지 준비한다고 약속하지 않는다는 점에 유의하세요. 18시나 19시가 될 수도 있습니다. 😅

React와 같은 좋은 라이브러리에서 꾸준히 발전하는 모습을 보니 반갑습니다. 🎉 class 를 사용하면 사용성이 훨씬 더 좋아집니다. 그만한 가치가 있습니다.

@gaearon

사용자 정의 요소와 일반 요소는 완전히 별개의 코드 경로입니다.

그 자체로도 고쳐야 할 부분인 것 같습니다. 모든 요소를 ​​동일하게 취급하지 않을 이유가 있습니까? 이것이 HTML 및 DOM 사양의 의도입니다.

@justinfagnani 이전에 논의한 바와 같이 당시에 하지 않은 이유는 속성 또는 속성을 설정할지 여부를 지정하는 방법에 대한 규칙이 없었기 때문입니다. 웹 플랫폼이 프로토타입에 새 속성을 추가하는 것은 불가능합니다. 지금 쯤이면 @robdodson 이 작업하고 있는 RFC 및 PR에 이미 일종의 합의가 있다고 생각하며, 아마도 거기에서 선택할 수 있을 것입니다.

👍 🔥 🔥 🔥

React Fire는 또한 Inferno가 가지고 있는 영리한 성능 최적화 중 일부를 적용할 수 있도록 해야 하지만 주요 변경 사항으로 인해 적용할 수 없었습니다. 신나는 시간들 :)

LGTM

제안된 className -> class 이름 바꾸기 관련: 문자열 배열을 사용하는 classes 속성을 원합니다. 그렇게 하면 구성 요소에서 많은 문자열 조작(또는 classnames 사용) 문제를 해결할 수 있습니다.

classes prop의 유일한 단점은 동일한 순서로 동일한 문자열을 포함하는 배열이 순수한 구성 요소에서 다시 렌더링되는 반면 동일한 CSS 클래스의 문자열은 그렇지 않다는 것입니다. 솔직히 말해서, 그것은 사소한 문제처럼 보입니다. 대부분의 React 개발자는 이미 props에서 배열과 객체의 장단점을 알고 있다고 생각합니다.

@gaearon 은 이전 버전과의 호환성에 대한 계획이 있습니까? React Fiber와 동일한 경로를 따라 변경 사항에 대한 경고를 추가하고 새로운 업데이트를 잃지 않고 대규모 코드베이스 업데이트에 시간을 줄 수 있습니다.

https://www.youtube.com/watch?v=F1U0qvtQnE8

class 및 className 관련.

우리가 어떤 길을 가든 이 문제에 대해 폭넓은 동의를 얻지 못할 것이라는 것을 압니다. 사람들은 이것에 대해 정말 강한 의견을 가지고 있습니다. 도움이 되었으면 하는 마음으로 제 생각을 공유하고자 합니다.

Component API는 관용적이어야 합니다.

React가 "JavaScript와 일치"하므로 className 가 선호된다는 공통된 주장이 있습니다. 이 주장은 미묘하게 오해가 있는 것 같아서 조금 집중해서 말씀드리고자 합니다.

React에서 우리는 무엇보다도 React 컴포넌트를 사용하는 것이 관용적인 JavaScript처럼 느껴져야 한다는 점에 주의를 기울입니다. 즉, 가상의 <Table> 구성 요소를 사용하는 경우 해당 props가 camelCase가 될 것으로 예상합니다.

<Table
  rowHeight={10}
  headerBorderInset={5}
  renderRow={this.renderRow}
/>

구성 요소의 공개 API 에서 row_height 또는 row-height 와 같은 소품 이름을 볼 것으로 예상하지 않습니다. Component의 props는 ("option bag"과 같은) 객체이며 일반적으로 이러한 옵션이 camelCase 것으로 예상합니다. 이것은 DOM에서 항상 관용적인 것은 아니지만 DOM은 많은 곳에서 일관성이 없습니다. React는 camelCase 를 압도적으로 사용하는 JavaScript 생태계와 일치합니다.

그러나 DOM은 어떻습니까? 이것은 가시가되는 곳입니다.

DOM 속성은 "JS의 속성"이 아닙니다.

DOM에는 속성과 속성이 있습니다. 속성은 일반적으로 HTML에서 볼 수 있는 것입니다. 속성은 일반적으로 JS에서 설정하는 것입니다. 그러나 결정적으로 DOM API는 속성을 설정하고 속성을 설정하기 위해 존재하며 항상 같은 것을 설정하지는 않습니다.

node.value = 10; // setting a property
node.setAttribute('value', '10'); // setting an attribute

많은 경우에 그것은 중요하지 않습니다. 어떤 경우에는 그렇습니다. 그러나 React(둘 모두에 대해 하나의 추상화가 있음)를 사용하여 생각할 수 있는 방식이 아닐 수도 있습니다.

React는 단순히 속성을 설정하는 것이 아닙니다.

일반적인 오해는 React가 현재 대부분의 DOM props에 대해 camelCase 규칙을 사용하기 때문에 React가 DOM 속성을 설정하고 있음을 의미한다는 것입니다. 이것은 잘못된 것입니다.

사실 React는 현재 지원하는 거의 모든 props에 속성을 사용하고 있습니다. 어떤 경우에는 value 와 같은 문제가 발생합니다(내가 논의한 대로 되돌리기를 원함). 다른 경우에는 지원되는 속성 목록을 React 번들에 포함할 필요가 없기 때문에 이것은 실제로 훌륭합니다. 후드 아래에서 속성을 사용함으로써 React 16에서 크기를 크게 줄일 수 있었습니다.

여기서 제 요점은 React가 내부적으로 속성을 사용하는지 속성을 사용하는지 여부는 구현 세부 사항 이며 React DOM 요소 _API_가 속성 이름, 속성 이름 또는 기타 의미 있는 이름을 사용해야 하는지 여부와는 아무 관련이 없다는 것입니다.

그래도 속성 이름을 사용합시다.

좋습니다. 속성과 속성은 구현 세부 사항입니다. 그러나 "JavaScript용"으로 특별히 제작된 DOM 속성 이름을 사용하여 표준화하지 않는 이유는 무엇입니까? 이것이 오늘날 React API가 설계된 방식이 아닙니까?

글쎄요. 아래에 열거된 props 중 하나만 실제 DOM 객체 속성에 해당합니다.

<div
  tabIndex={1}
  data-id="123"
  aria-live="polite"
  nopin="nopin"
  itemType="http://schema.org/Movie"
  onClick={function() { alert('hi') }}
/>

아이러니하게도 동일한 이름을 가진 실제 DOM 속성이 있는 위의 유일한 prop(확실하지 않은 경우 tabIndex )은 실제로 React에 의해 속성으로 설정됩니다!

따라서 이 시점에서 아마도 명확하지도 않고 일관되지도 않다는 것을 알 수 있을 것입니다. 어떤 경우에는 속성이 존재하지 않습니다(예: 사용자 정의, 비표준 속성). 어떤 경우에는 React가 더 풍부한 API( data- vs dataSet )를 제공할 수 있지만 현재는 그렇지 않습니다.

어떤 경우에는 사용자 정의 React 구성 요소에 더 적합하기 때문에 React가 의도적으로 편차를 선택합니다( React의 onClick 대 onclick DOM 속성). 이는 React 구성 요소가 종종 onItemClick 와 같은 더 복잡한 이벤트 핸들러를 노출하기 때문입니다. <Button onclick> 하지만 <Table onItemClick> 라고 쓴다면 매우 일관성이 없을 것입니다. 그리고 <Table onitemclick> 는 컴포넌트 API에서 피하고 싶었던 camelCase가 아닙니다.

위에서 나는 React가 이미 "항상 DOM 속성 이름을 사용"하는 것과 관련하여 일관성 이 없고 , React가 실제로 속성을 내부적으로 사용하지도 않는다는 점(그래서 경험 법칙도 실제 메커니즘을 설명하지 않음)에 대해 설명했습니다. 경우 DOM 속성은 단순히 존재하지 않으므로 속성 이름을 계속 허용해야 합니다.

속성 이름이 아니면 일관성을 유지하고 속성 이름을 사용합시다?

그렇다면 속성 이름 만 사용하는 것은 어떻습니까? 이것은 그럴듯할 수 있습니다. 그러나 이제 우리는 우리가 제기한 첫 번째 고려 사항에 부딪힙니다. React 구성 요소를 사용하는 것은 관용적인 JavaScript처럼 느껴져야 합니다 . 그러나 종종 구성 요소는 기본 DOM 요소에 최소한 일부 소품을 전달합니다.

<Button
  borderColor='red'
  tabIndex={1}
 />

 // renders...

 <button
   tabIndex={1}
/>

맞춤 Button 에서 대문자가 일치하지 않는 소품을 수락하는 것은 어색할 것입니다.

<Button
  borderColor='red'
  tabindex={1}
 />

이렇게 하면 소비자가 특정 prop이 실제 DOM prop인지, 아니면 구성 요소 계약의 일부인지 항상 기억해야 합니다. 그 구분조차 모호합니다. 구성 요소는 먼저 특정 소품을 통과하도록 선택할 수 있지만 실제로는 추가 논리에 사용하기 시작할 수 있습니다. "DOM props"와 "other props"의 경계를 어디에 두나요?

이것이 tabIndex , cellSpacing 와 같은 props 및 대부분의 다른 DOM 관련 props가 camelCase 규칙을 따르는 것이 바람직한 주된 이유라고 생각합니다. 컴포넌트 API로 끝나는 경우가 많기 때문입니다.

우리는 Button 와 같은 사용자 정의 구성 요소가 DOM으로 흘러 들어가는 지점에서 속성 이름으로 "변환"하지 않고, 그리고 non-camelCase 소품을 사용자 정의 구성 요소 API.

이것은 또한 data-* , aria-* 및 사용자 정의 속성과 같은 소품이 합리적인 예외인 이유를 설명합니다(비록 더 풍부한 API를 만들 수 있음에도 불구하고). 사용자 지정 구성 요소에 거의 전달되지 않습니다. 일반적으로 DOM에 너무 결합되어 사용자 정의 구성 요소에서 유용하지 않습니다. 대신 더 풍부한 camelCase API를 사용하여 <Modal> 또는 <Button> 와 같은 구현 세부 사항이 됩니다.

React 속성이 이미 DOM 속성과 일치하지 않습니다.

"DOM 속성 이름" 규칙이 작동하지 않으면 다른 것이 필요합니다. 그것은 무엇입니까? "속성 이름의 camelCase 버전"이 될 수 있습니까? 이것은 거의 항상 이미 체크 아웃되는 것 같습니다.

이것이 너무 급진적으로 들린다면 우리가 이미 이것을 하고 있다고 생각하십시오. 우리는 srcSet 라는 것을 지원합니다. 그러나 DOM 속성 이름은 srcset 입니다. autoCapitalize 가 있지만 DOM 속성은 autocapitalize 입니다. autoFocus 가 있지만 DOM 속성은 autofocus 입니다.

camelCase JavaScript 규칙과 일치하지 않을 때 이미 DOM 속성 이름에서 벗어나고 있습니다. 이것은 우리를 class 만듭니다.

마지막으로: className 대 class

className 로 만든 이유 중 일부는 React가 DOM 속성을 설정하고 className 가 DOM 속성의 이름이기 때문입니다.

그러나 위에서 설명한 것처럼 React는 3~4개의 특별한 경우를 제외하고는 더 이상 속성을 사용하지 않습니다. 더 중요한 것은 React는 DOM 속성 이름을 일관되게 사용하지도 않습니다. 대신 DOM 속성과 속성 이름의 내부 명명 불일치에 관계없이 JavaScript에서 사용할 때 자연스럽게 보이는 이름을 사용합니다. React는 커스텀 컴포넌트의 prop 이름을 "JavaScripty"로 느끼도록 유지하는 데 가장 신경을 쓰기 때문입니다. 이런 의미에서 tabindex 는 "JavaScripty"가 아니지만 class 와 className 는 모두 "JavaScripty"입니다.

초기에 class 에 대한 또 다른 주장은 다음과 같은 코드가 유효한 ES3(IE8과 관련됨)가 아니라는 것입니다.

// Not valid in ES3
// Valid in ES5
var props = { class: 'foo' };

그러나 대부분은 더 이상 ES3를 작성하지 않습니다. Babel과 같은 도구 모음을 사용하거나 IE9+를 대상으로 할 가능성이 높습니다. React는 현재 IE8을 지원하지 않습니다.

따라서 class 에 남아 있는 유일한 불편은 다음을 작성할 수 없다는 것입니다.

// Not valid at all :-(
const class = props.class;
const { class } = props;

그러나 시간이 지남에 따라 이 주장은 그 자체로 충분히 강력하지 않다고 생각합니다. React는 구조화를 사용하거나 이 특정 변수 이름을 사용하고 다음과 같은 것을 작성하도록 강요하지 않습니다.

// Valid
const {class: cls} = foo;
const cls = props.class;

그 이상의 노력이 필요하지 않습니다.

일반적으로 많은 구성 요소에 하나 이상의 내부 <div> 또는 기타 호스트 요소가 포함되어 있기 때문에 사람들은 class 를 읽는 것보다 훨씬 더 자주 전달합니다. 따라서 class 를 구조화하려는 것보다 훨씬 더 자주 <div className> 를 작성하게 됩니다. 따라서 class 로 변경하면 도입되는 것보다 더 많은 키보드 입력을 절약할 수 있습니다.

여기에 또 다른 중요한 포인트가 있습니다.

class 를 여러 수준으로 전달하는 것은 그 자체로 좋은 패턴이 아닙니다. 라이브러리에는 필요하지만 애플리케이션 코드에서는 종종 취약한 구성 요소로 이어집니다. 각각 다른 클래스를 추가하는 100개의 서로 다른 호출 사이트가 있기 때문에 스타일이 항상 깨지고 캐스케이드 버그가 발생합니다. 따라서 class 를 처음부터 구조화하도록 권장하는 것이 얼마나 가치 있는 것인지 명확하지 않습니다. props에서 읽기 위해 코드를 한 줄 더 작성해야 한다고 생각합니다(또는 props.class 를 사용하고 그것에 대해 생각하지 않아도 됩니다).

DOM에 매우 가까운 구성 요소 를 작성하는 경우(따라서 class 를 소품으로 사용하는 것이 합리적임) 다른 소품도 전달하고 싶을 것입니다. 따라서 구조화에 나머지 구문을 사용할 수 있습니다.

// Valid in ES2018

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

수정할 필요가 없다면 class 를 읽지 않고도 {...rest} 를 전달했을 수 있습니다. 따라서 구조 분해 제한은 더 나은 구성 요소 디자인을 장려하는 데 도움이 될 수 있습니다.

왜 모두?

마지막으로 class 와 className 를 모두 지원할 수는 없나요? 어떤 면에서는 이미 그렇게 하고 있지만 React는 경고와 함께 당신에게 고함을 지릅니다. 여기에는 이유가 있습니다.

경고 없이 둘 다 지원하면 커뮤니티에서 어느 것을 사용할지 쪼개집니다. class prop을 받는 npm의 각 구성 요소는 둘 다 전달해야 한다는 것을 기억해야 합니다. 중간에 하나의 구성 요소라도 작동하지 않고 하나의 소품만 구현하면 클래스가 손실됩니다. 그렇지 않으면 하단에 class 및 className 가 각각 "동의하지 않음"으로 표시될 위험이 있습니다. React가 그 충돌을 해결할 방법이 없습니다. 그래서 우리는 그것이 현상 유지보다 나쁠 것이라고 생각하고 이것을 피하고 싶습니다.

요약

React가 오늘날 오픈 소스라면 class (대부분의 사람들이 기대하는 것과 개념적으로 더 가깝고 가장 일반적으로 사용되는 prop에 대한 타이핑이 적음)을 허용하는 장점이 단점(차단하기 위해 약간 더 많은 타이핑을 하는 것)보다 중요한 것처럼 보입니다. 어쨌든 스프레드 연산자를 원할 것입니다).

우리가 DOM 속성과 일치하지 않는 단점으로 보았던 것은 더 이상 DOM 속성을 설정하지도 않고 일관성을 유지하려고 노력하지도 않기 때문에 무의미합니다. 대신 우리는 이미 거의 일관성을 유지하고 있는 React 구성 요소의 소비 측에서 속성 기반이지만 camelCase API를 목표로 하고 있습니다. 그리고 class="Button" 가 className="Button" 보다 확실히 더 편리합니다. 사실 DOM API가 오늘날 설계되었다면 .class 속성을 설정할 수 있을 것입니다. 거의 10년 전에 이와 같은 할당에서 class 사용에 대한 제한이 ES5에서 해제되었기 때문입니다.

유일하게 남은 큰 단점은 마이그레이션 비용입니다. 우리는 이것을 신중하게 평가할 것입니다. 그러나 어쨌든 우리가 많은 변경을 하고 있다면 이것 역시 만들고 영원히 고칠 수 있을 것입니다. 우리는 이것을 가볍게 생각하지 않으며 귀하의 모든 우려 사항을 고려합니다.

참고: 이것은 camelCased 속성 이름과 일치하지 않는 다른 React prop 이름에 대해 수행하는 것이 합리적일 수 있습니다.

@renatoagds

이전 버전과의 호환성에 대한 계획이 있습니까? React Fiber와 동일한 경로를 따라 변경 사항에 대한 경고를 추가하고 대규모 코드베이스 업데이트에 시간을 할애할 수 있습니다.

내가 언급했듯이 :

그리고 Facebook에는 마이그레이션 전략에 대해 정직하게 설명할 수 있는 50,000개 이상의 구성 요소가 있습니다. 몇 가지 대상 수정 또는 자동화된 코드 모드를 제외하고는 제품 코드를 다시 작성할 여유가 없습니다.

그래서 우리는 언제나처럼 마이그레이션 전략을 최대한 원활하게 만들려고 노력할 것입니다. 매끄럽지 않으면 스스로 변경할 수 없습니다.

re: className -> class, 어떤 결정을 내리든 괜찮습니다. 새로운 사용자를 위한 클래스 변경 예외와 더 짧은 코드 줄의 부수적 이점을 확실히 알 수 있습니다. 하지만 여전히 다른 camelCase 이름에 대해 알아야 합니다.

따라서 클래스에 남은 유일한 불편은 다음과 같이 작성할 수 없다는 것입니다.

const { class } = props;

그러나 시간이 지남에 따라 이 주장은 그 자체로 충분히 강력하지 않다고 생각합니다. React는 > 구조화 및 쓰기를 사용하도록 강요하지 않습니다.

const class = props.class;

그 이상의 노력이 아니다.

두 가지(작을 수도 있음):

1. const class = props.class 자바스크립트가 유효하지 않습니까? 나는 그것이라고 생각하지 않았고 빠른 테스트에서 Chrome은 그것을 좋아하지 않습니다. 또한 이 기사 는 유효하지 않음을 나타냅니다.

2. 이 변경 사항이 nvm과 같은 구성 요소를 작성하는 사람들에게 (다시 한 번, 잠재적으로 작은) 좌절의 영역임을 알 수 있습니다(아래 업데이트 참조).

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    className={someClassName}
    {...rest}/>
);

이 변경 후에는 다음과 같아야 합니다.

const { oneProp, twoProp, ...rest }  = this.props;

// do stuff with oneProp, twoProp, this.props.className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    {...rest}
    class={someClassName}/>
);

이 변경 사항을 해결하는 것이 불가능한 것은 아니지만 이 스타일로 구성 요소를 작성하고 읽을 때 유념해야 할 사항이 조금 더 있습니다.

업데이트 :

신경 쓰지 마,

const { class: className } = this.props;

트릭을 수행합니다.

유일하게 남은 큰 단점은 마이그레이션 비용입니다. 우리는 이것을 신중하게 평가할 것입니다. 그러나 어쨌든 우리가 많은 변경을 하고 있다면 이것 역시 만들고 영원히 고칠 수 있을 것입니다. 우리는 이것을 가볍게 생각하지 않으며 귀하의 모든 우려 사항을 고려합니다.

운 좋게도 이것은 Aesthetic와 같은 CSS-in-JS 접근 방식을 사용하는 경우 쉽게 완화됩니다. 놀라운 작성 주셔서 감사합니다!

속성 이름에 관한 임의의 팁, 나는 훌륭한 프로젝트를 발견했습니다. svg2jsx 는 큰 SVG를 React에서 사용하도록 변환하는 데 좋습니다!

@jamesPlease 죄송합니다, 내 마음이 비어 있습니다 — 당신 말이 맞아요. 수정됨.

@james 당신이 옳습니다. 그것은 또한 기본 값에 대해 JSON과 자주 작동하므로 성가신 일입니다!

const { default: defaultVal } = property

이벤트 시스템을 변경하는 동안 Inferno의 linkEvent 함수와 유사한 것을 보는 것이 정말 좋을 것이므로 렌더링할 때마다 익명 함수를 만들 필요 없이 기능 구성 요소에서 props를 사용하여 이벤트 처리를 수행할 수 있습니다.

className -> class 는 생태계에 큰 변화가 될 것이며 유지 관리되지 않은 수많은 구성 요소가 호환되지 않으며 패치하지 못하면 할 수 있는 일이 없습니다. 점진적인 마이그레이션 경로를 제공하기 위해 트리의 더 깊은 구성 요소에 대해 이러한 변경을 비활성화하는 StrictMode 와 같은 래퍼가 있습니까?

이 변경이 다음과 같은 구성 요소를 작성하는 사람들에게 (다시 한번, 잠재적으로 작은) 좌절의 영역임을 알 수 있습니다.

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
 <div className={someClassName} {...rest}/>
);

구조화하지 마십시오.

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div
    {...rest}
    class={'something ' + rest.class}
  />
);

@gaearon

React가 내부적으로 속성을 사용하는지 속성을 사용하는지 여부는 구현 세부 사항입니다.

그것도 솔직히 문제인 것 같다. DOM 요소는 속성을 설정하는지 속성을 설정하는지에 따라 경우에 따라 다르게 동작할 수 있고 동작합니다. React는 모든 차이점을 알 수는 없지만 요소 사용자는 자신이 사용하는 요소에 대해 알 수 있습니다. 속성, 속성 및 이벤트에 대한 명시적 제어를 통해 작성자는 이러한 상황에서 벗어날 수 있습니다.

@justinfagnani 변경 했으면 하는 특정 사항이 있는 경우 제안하는 API에 대해 별도의 문제를 제출해도 될까요? 이것은 이 문제의 범위를 약간 벗어난 것 같습니다.

@sompylasar

className -> class는 생태계에 큰 변화가 될 것이며, 유지 관리되지 않는 수많은 구성 요소가 호환되지 않을 것이며, 패치하지 못하면 할 수 있는 일이 없습니다. 점진적인 마이그레이션 경로를 제공하기 위해 트리의 더 깊은 구성 요소에 대해 이러한 변경을 비활성화하는 StrictMode와 같은 래퍼가 있습니까?

동의합니다. 그리고 우리는 여전히 찬반 양론을 저울질하고 있습니다. 아무것도 확정되지 않았습니다.

그러나 실제로 유지 관리되지 않는 구성 요소의 문제는 새로운 것이 아닙니다. 정의에 따라 메이저에서 무언가가 변경되기 때문에 모든 React 메이저 릴리스에 나타납니다(그렇지 않으면 앞으로 나아갈 수 없으며 모든 레거시 코드를 예를 들어 서버 환경과 달리 번들은 영원히). PropTypes 가 별도의 패키지로 이동할 때도 동일한 문제가 발생했으며 UNSAFE_ 수명 주기 이름을 변경하면 다시 발생합니다. 유지 관리되지 않은 패키지는 분기되거나 패치됩니다. 우리는 그것이 큰 시간 손실임을 깨닫고, 이것이 우리가 1년에 하나 이상의 큰 전공을 하는 것을 피하는 이유입니다. 도움을 줄 여유가 없는 사람들의 경우, 얼리 어답터가 길을 닦고 버려진 패키지를 되살리기 때문에 일반적으로 새 전공으로 옮기기 전에 몇 달을 기다리는 것이 가장 좋은 전략입니다. 그런 다음 우리는 모두 함께 앞으로 나아갑니다.

다시 한 번 — 귀하의 주저함을 충분히 이해합니다. 그러나 이는 주로 과거에 발생했거나 미래에 발생할 수 있는 다른 주요 변경 사항과 크게 다르지 않습니다. 언제나처럼, 우리는 대부분의 코드베이스를 변환하기 위해 실행할 수 있고 다른 패키지에서도 실행할 수 있는 자동화된 스크립트에 많은 노력과 강조를 가할 것입니다(그리고 PR을 보내거나 마지막 상태에서 포크) ).

결정에 관계없이 class 에 대한 또 다른 주장은 검색 가능성입니다. JS 클래스 구성 요소를 사용하는 ES6 코드에서 CSS 클래스를 사용하는 구성 요소를 찾고자 할 때 class 로 검색하면 오탐지가 몇 개나 될까요? 예, class={ 를 검색할 수 있지만 JS에서 객체로 생성된 JSX의 props를 구조화하는 것은 어떻습니까? (저는 props destructuring을 많이 사용하는 것을 반대하지만 여전히 사용 중입니다.) 물론 코드 편집기에서 더 나은 컨텍스트 인식 AST 기반 검색 도구가 필요하지만 지금은 텍스트와 정규 표현식만 있습니다. 물론 유형 시스템은 객체 전달을 추적하는 데 도움이 될 수 있지만 많은 인구가 이를 채택하지 않았습니다.

예약어를 사용하는 것과 관련하여 지금 은 문제가 발생하지 않더라도 저와 어울리지 않습니다. rest.class (예를 들어)가 x년 안에 언어에 중요하지 않을 것이라고 확실히 말할 수 있습니까?

@GeordieP 오늘 작동하면 내일 깰 수 없습니다. 이것이 자바스크립트가 어떻게 진화하고 있는지에 대한 핵심 원칙이자 많은 특징이 있는 이유입니다.

@gaearon 그럼 충분합니다. 그것이 충분히 큰 승리라면, 나는 그것을 위해 가라고 말합니다.

@sompylasar 저는 일반적으로 className= 또는 className: 를 검색합니다. 이 두 가지 모두 class 에서도 작동하는 것 같습니다.

className 를 제거하십시오. 그리고 맙소사 htmlFor . 저는 DOM 개발자가 아닙니다. 일반적으로 기본 DOM 메서드에 액세스해야 하는 경우 매우 잘못된 문제가 있습니다. 내가 React에 사람들을 온보딩하는 가장 큰 도전은 JSX가 DOM과 그 이상한 대체 HTML 속성에 대해 만드는 추상화입니다. 모든 것이 변환되고 있으므로 이 시점에서 예약어에 대해 걱정할 이유가 없습니다. IMO.

이것이 기존 토론에 아무것도 추가하고 있는지 확실하지 않지만 className 를 변경해야 하는 더 나은 이유가 있는 것 같습니다.

약간 직관적이지 않은 이름에서 초보자 React 학습자를 저장하는 것이 모든 사람이 프로젝트 및 행동을 업데이트해야 할 가치가 있습니까?

구조 해제를 자유롭게 사용하는 사람으로서 규칙에 대한 이 새로운 예외를 기억해야 하는 것은 내가 $# className class 라고 쓰는 드문 경우보다 더 큰 정신적 문제일 것입니다.

또한 초보자는 현재 className 를 사용하는 방대한 양의 자료(블로그/리포지토리 등)에 여전히 혼란스러워하지 않습니까?

마지막으로 @sompylasar 가 말했듯이 이것은 내 코드베이스 내에서 검색 가능성을 손상시킵니다.

아마도 이것은 탭 대 공백 유형 인수이지만이 변경이 필요한 이유를 완전히 이해하지 못합니다. 시간이 지남에 따라 API를 모델링하려는 방식의 더 큰 변화의 일부가 아니라면 약간의 이득을 위한 큰 비용처럼 보입니다. 그건 그렇고, 나는 당신이 결정한 것을 확실히 사용하겠습니다 😂.

약간 오프탑이지만 (내가 아는 한) 아무도 HTML 속성을 매핑하는 사소한 변경으로 React로의 마이그레이션을 쉽게 하기 위해 html/css/svg -> jsx 변환기를 만들 생각을 하지 않았다는 것은 다소 슬픈 일입니다. 리액트 소품.

@jxub - 2014년에 해커톤 방식의 일부로 HTML에서 JSX로 변환기를 만들었습니다. https://magic.reactjs.net/htmltojsx.htm. 그러나 SVG를 잘 처리하는지 확실하지 않습니다. hackathon 프로젝트는 React(https://github.com/reactjs/react-magic)를 사용하여 일반 HTML 사이트를 "ajaxify"하는 스크립트를 만드는 것이었고 그 중 일부는 React 구성 요소를 만드는 방법을 구축해야 했습니다. HTML 덩어리에서 HTML to JSX 부분을 별도의 독립형 페이지로 릴리스했습니다.

우리는 여전히 IE11 지원에 신경을 쓰고 있지만 기존의 브라우저 차이점 중 일부를 매끄럽게 만들지 않을 가능성이 있습니다. 이는 많은 최신 UI 라이브러리가 취하는 입장입니다.

@gaearon - 브라우저 차이를 매끄럽게 처리하지 못하는 최신 UI 라이브러리의 예는 무엇입니까? 저에게 그것이 라이브러리를 사용하는 주요 이유 중 하나입니다.

음모 이론: 이 전체 className / class 뉴스는 모두가 즉시 주의를 기울이고 이에 대해 논쟁할 밝은 논쟁의 여지가 있는 것입니다. 재작업 프로젝트 전체에 대한 관심을 끌거나, 그림자 속에서 일어나고 있는 더 큰 일로부터 주의를 돌리거나, 다음 일화에서처럼 나중에 철회할 수 있는 한 가지를 주고 나머지는 받아들일 수 있습니다.

위대한 연극 예술가 Tyshler는 풍경의 스케치를 만들고 구석에 작은 녹색 개를 그립니다. 그리고 입학 심사위원 중 한 명이 "나는 다 좋은데 이 개는 어디 있지?"라고 묻자 안타까운 한숨을 내쉬며 그녀를 붙잡았다.

이 변경의 진정한 이유는 명확하지 않지만 이미 이 새로운 업그레이드 프로젝트의 인기와 React에 대한 커뮤니티의 소문이 급상승했습니다.

Passive Event Listeners 지원이 모바일의 중요한 기능인 React Fire의 범위 안에 있다면 좋을 것입니다.

6436

이 작업에 대한 모든 노력에 감사드립니다. 하지만 className -> class 를 재고해 주세요.

우리는 모두 한때 React 초보자였으며 className 는 우리가 React를 배우고 사랑하는 것을 막지 못했습니다.

jsx와 함께 vue를 사용할 때 이미 class 가 className $ 가 아닌 것으로 기억합니다. React가 Virtual DOM의 선구자이기 때문에 className 이 class 로 변경되는지 여부에 동의하지 않습니다. , DOM 자체를 나타냅니다.

문서가 아닌 React 루트에 이벤트를 첨부하십시오.

@gaearon 이것은 테스트 환경에서 실제 브라우저 이벤트를 전달하고 그에 연결된 핸들러를 호출할 수 있도록 문서에 요소를 추가할 필요가 없다는 것을 의미합니까? 이 작업을 수행해야 하는 것은 매우 직관적이지 않으며 React의 내부에 익숙하지 않은 많은 개발자가 혼란스러워하고 테스트를 작성하는 데 많은 시간을 낭비하고 이벤트 시뮬레이션 및 열악한 테스트 사례를 발생시키는 원인이 되었다고 확신합니다.

react-dom/test-utils 에 대해 뭔가를 할 수 있을까요? 저는 특히 우리 모두가 알고 있는 관련된 모든 문제를 감안할 때 Simulate 의 가능한 제거에 관심이 있으며 물론 react-dom 자체에서 필요한 변경을 수행하여 실제로 필요하지 않도록 합니다. 더 이상. 범위에 해당될 수 있습니까?

/cc @kentcdodds

나는 React Fire가 취하고 있는 방향과 큰 그림을 좋아합니다. 지금까지 그것들은 노력해야 할 큰 변화처럼 보입니다.

대부분의 발표된 변경 사항을 좋아하지만 className 변경 사항에 대해서는 회의적입니다.

React는 구조화를 사용하거나 이 특정 변수 이름을 사용하도록 강요하지 않으며 (...code snippet...)과 같은 것을 작성하는 것은 그렇게 많은 노력이 필요하지 않습니다.

작성하는 데 많은 노력이 필요하지는 않지만 현재 경험으로는 다른 개발자(특히 다른 언어의 개발자)에게 설명하기가 _방법_ 더 어려울 것으로 예상합니다. 반면에 우리는 우리 회사에서 React를 사용하면서 몇 년 동안 className 에 혼란스러워 하는 개발자가 한두 명뿐이었던 것 같습니다. 그리고 이것을 Reacts API로 받아 몇 분 안에 클래스 이름을 설정했습니다.

(내 개인적인 의견으로는 내가 파괴하는 것을 _사랑_하는 동안, 이름 바꾸기 구문은 때때로 초보자에게 그 자체로 이상하게 느껴질 수 있습니다. 매우 유사하게 보이고 기본값과 같은 것들과 결합될 수 있는 가져오기에서 이름 바꾸기와 다르기 때문입니다. , 그러나 그것은 우리가 현재 우리 회사에서 작성하는 다른 모든 코드에 대한 _큰_ 예외가 될 것입니다. 다른 사람의 경험 물론 다를 수 있지만 문제에 대한 제 견해입니다 🙃.)

엄청난

또한 className 변경에 대해 회의적입니다. 그것은 사물의 계획에서 가장 사소한 변경 중 하나이지만 여기에서 논평 토론의 거대한 덩어리를 끌어들이고 있습니다.

발표되고 있는 다른 좋은 것들이 너무 많은데, 변화에 그렇게 많은 정치적 자본을 투자할 가치가 있습니까?

내가 서 있는 위치에서 정당화의 일부가 "그리고 다음과 같은 것을 작성하는 것이 ... 훨씬 더 많은 노력이 필요한 것이 아닙니다."인 결정을 내리고 있다면 그 결정은 _거대한_ 긍정적인 측면이 있어야 합니다. className -> class 변경은 발표된 다른 모든 것과 비교할 때 크게 다르지 않습니다.

이것은 🔥 React Fire의 주요 발전이 될 것입니다

class v/s className 에 대해 JSX ≠ React를 상기시켜야 한다고 생각합니다.

JSX는 HTML처럼 보이도록 설계된 _DSL_이므로 가능한 한 HTML에 가깝게 유지하는 것이 가장 좋습니다. DOM API에서는 className 라고 하지만 대부분은 DOM API를 직접 다루기를 원하지 않기 때문에 대부분 JSX를 사용하고 있습니다.

React의 API가 DOM API와 밀접하게 일치하는 것이 더 합리적이라면 변환에서 매핑을 수행하는 것이 괜찮거나 가능하기를 바랍니다.
<img src="avatar.png" class="profile" /> → React.createElement("img", { src: "avatar.png", className: "profile" }) .

JSX 구문을 HTML의 깨끗한 상위 집합으로 만드는 것은 매우 중요합니다.

@mhenr18 이 말한 내용에 추가합니다.

현재 상황:

• 반응이 일관성이 없습니다
• API는 camelCase입니다.

제안된 상황:

• 반응이 일관성이 없습니다
• API는 camelCase입니다.
• className -> class

인지된 이점:

React가 오늘날 오픈 소스라면, 클래스를 허용하는 것(대부분의 사람들이 기대하는 것과 개념적으로 더 가깝고 가장 일반적으로 사용되는 prop에 대한 타이핑이 적음)의 장점이 단점(차단하기 위해 약간 더 많은 타이핑을 하는 것)보다 중요한 것처럼 보입니다. 어쨌든 스프레드 연산자를 원할 것입니다).

실제 단점:

• className 에 의존하는 전체 생태계가 작동을 멈춥니다(거대한 업그레이드 노력)
• 책, 튜토리얼, 예제, 코드, 게시물, 기사의 방대한 본문 전체가 조금씩 무효가 됩니다.
• 남아있는 유일한 유효한 JS는 추가 타이핑 : const {class: cls} = props 입니다. 일반 JS의 다른 모든 가능한 사용 사례는 무효화됩니다.
• React API는 일관성이 없고 추가 가정을 깨고 있습니다( for htmlFor 가 아닌 이유 등).

내가 제품 관리자라면 변경 사항에 대한 즉각적인 반응은 다음과 같습니다. 와트?

@gaearon 이미 고려하셨을 텐데 "React Fire" 또는 이와 유사한 키워드로 PR을 태그하십시오.

문제는 일반적으로 올바르게 태그가 지정되지만 PR에는 없는 경우가 있습니다. 이는 잠재적 기여자에게 도움이 됩니다.
이것은 전체 Fiber 개발 중에 React Fiber 및 React Reconciler 관련 커밋을 찾는 git 기록을 읽으려고 할 때의 경험에서 나온 것입니다. 무슨 일이 일어나고 있는지 파악하고 우리가 어떤 식으로든 기여할 수 있는지 알아보려는 사람들에게 도움이 됩니다.

또한 className 의 이름을 class 로 변경하면 새로운 개발자에게 큰 마이그레이션 노력과 문제가 발생할 것이라고 생각합니다.
className 속성은 너무 눈에 띄고 많이 사용되어 말 그대로 반응에 의존하는 모든 라이브러리를 깨뜨릴 것입니다.
그리고 이것으로는 충분하지 않습니다. 대부분의 튜토리얼은 깨질 것입니다. 기사에서 새 장치 복사 및 붙여넣기는 "왜 작동하지 않는지, className 는 유효한 소품이 아닙니다"라고 궁금해할 것입니다.
그래서 선배는 도와야 하고 우리는 아무 것도 얻지 못했습니다. 왜냐하면 우리는 여전히 당신이 기대하는 것처럼 작동하지 않는 이유를 설명해야 하기 때문입니다.
그리고 실제로 className 를 사용하여 구성 요소의 클래스를 정의해야 한다고 설명하는 데 1분이 채 걸리지 않으며 쉽게 이해할 수 있습니다. className 에서 class 로 변경한 이유를 모든 개발자에게 설명하는 것은 훨씬 더 오래 걸리고 더 많은 좌절을 초래합니다.

한 단어에 필요한 모든 노력.
반응이 동작하는 방식에는 아무 것도 변경되지 않습니다.
react-dom의 개발을 촉진하지 않습니다.
반응으로 일주일 이상 일하는 개발자의 생산성을 증가시키지 않습니다.
그것은 모든 것을 깨뜨릴 것입니다.

생각해보십시오, 정말 가치가 있습니까?

나는 babel-plugin-react-html-attrs 를 몇 년 동안 사용해 왔으며 잘 작동하고 있습니다 className 의 이름을 class 로 바꾸는 것은 좋은 생각이 아닙니다. 내가 언급한 것과 같은 플러그인을 사용하면 더 좋습니다.

" class v className " / " for v htmlFor " 상황 전체를 처리하는 Babel 플러그인 이 없었나요?

이미 결정된 명명 결정과의 하위 호환성을 유지하면서 html 속성을 있는 그대로 지원할 수 있기를 바랍니다.

변환을 수행할 babel 플러그인이 이미 있다는 사실은 아마도 코어 JSX 트랜스파일러 자체에서 이를 지원하는 것이 가능해야 한다는 증거일 것입니다. 그러나 공식 사양으로 만들면 모든 사람이 훨씬 더 쉽고 신뢰할 수 있습니다.

나는 React 내부에 대해 알지 못하므로 실제 가능성에 대해 많이 말할 수 없습니다. 사용자 친화성 측면에서 "해야" 한다고 생각하는 방식만을 표현합니다.

className 대 class 를 재고하십시오. 위에서 말했듯이 이득은 거의 존재하지 않지만 실질적인 단점이 있습니다.

하나는 반응 응용 프로그램을 작성하기 위한 언어로 Hax를 사용하는 우리에게 이것은 획기적인 변경일 뿐만 아니라 단순히 _any_ 반응 응용 프로그램을 작성하는 것을 방지한다는 것입니다.

class 는 대부분의 프로그래밍 언어에서 예약된 키워드이며 더 이상 이 소품을 조작할 수 없어 반응 응용 프로그램을 거의 불가능에 가깝게 만들었습니다(클래스를 조작하지 않고 실제 응용 프로그램을 만드는 데 행운을 빕니다). htmlFor 대 for 도 마찬가지입니다. 슬프게도 (이것은 정말 못생겼지만 존재하는 것에 감사합니다).

아 그건 그렇고, 검색 가능성이... "React 클래스"에 대해 Google에서 검색한다고 상상해 보세요. React 클래스 구성 요소, React 클래스 속성과 같은 혼합 신호를 받게 됩니다. "React className"을 검색하면 오래된 문서를 얻게 됩니다(위에서 언급한 사람들은 코드 업그레이드 외에 이 변경으로 인해 발생하는 엄청난 양의 업그레이드 작업).

이 프로젝트의 목표는 커뮤니티를 위한 더 많은 작업과 인터넷을 위한 더 많은 잡음과 혼합 신호를 생성하는 것입니까? 내가하지 희망.

예, 웹 및 JavaScript 생태계는 과거의 어리석은 실수로 역호환을 유지하기 위해 고군분투하고 있습니다. 그러나 역호환을 위한 이러한 노력 덕분에 주요 파편화 없이 그러한 규모로 성장할 수 있었습니다.

나는 변화 없이는 진전이 없다는 것을 이해하고, 빨리 움직이기 위해 일을 부수는 초기 FB의 모토를 채택했습니다.

이 변경이 정말로 필요한 만큼 끈기 있게 행동한다면 변경의 진정한 이유를 말하십시오. 그것은 "배우기 어려운" 일이 아닙니다. 강력한 React Core 팀에게는 너무 얕게 들립니다. 당신은 확실히 뭔가를 염두에 두어야 합니다.

@sompylasar 나는 일반적으로 className= 또는 className:을 검색합니다. 이 두 가지 모두 클래스에서도 작동하는 것 같습니다.

또한 github에서 직접 수행하는 행운을 빕니다 =/

여기 댓글 다 읽었습니다. 변경 사항은 괜찮지만 class 에 대해서는 잘 모르겠습니다. 주된 이유는 JSX 2.0 계획에서 작동하지 않기 때문입니다. 바로 가기 표기법에 대해 (지금 개체에 있는 것처럼).
다른 모든 것은 매우 좋은 개선 사항인 것 같습니다.
최종 결정을 기다리고 있습니다 :) 놀라운 노력에 감사드립니다!

귀하의 의견 중 하나에서 "오늘 작동하면 내일 작동해야 합니다"라고 언급했습니다. 내가 묻기 전에 이것을 명심하십시오 ;).

저는 모든 버전의 React를 15.4로 되돌리는 RMWC https://jamesmfriedman.github.io/rmwc/ 라는 UI 라이브러리를 유지 관리합니다. 통합 API 표면을 유지할 수 있었지만 className을 class로, onChange를 onInput으로 변경하고 이벤트 시스템을 정밀 검사하면 계속하기가 거의 불가능해집니다.

후드 아래에서 이 항목의 일부를 번역할 수 있는 "호환" 레이어의 가능성이 있습니까? 따라서 반응 화재가 어떤 버전이든 작성할 수 있지만 더 낮은 런타임에서 계속 실행됩니다.

그렇지 않으면 내 이상한 코드가 더 이상해질 것으로 예상합니다. 👀

className 가 실제로 class 로 변경되어야 하는 경우 htmlFor 도 for 로 변경하십시오.
$ props 를 구조화할 때 class 및 for 가 원래 유효하지 않기 때문에.

React에 일관된 API를 만들기 위해 많은 속성 이름을 정규화하는 자체 API가 있다면 확실히 className 가 이에 완벽합니다. camelCase 관용구에 대한 추가 관용적 학습과 DOM 속성 이름(일부 다른 JSX 속성과 마찬가지로)에 매핑된다는 사실은 사용할 때마다 이를 특별한 경우로 구조화해야 하는 것과 비교할 때 확실히 괜찮습니다. props 객체가 켜져 있습니다.

지금까지 현상 유지에 반대하는 목소리를 많이 들은 것 같습니다("왜 수업을 못 듣나요?!"). 사용에 만족하는 모든 사람들은 조용히 있었습니다. 사람들이 긍정적인 리뷰보다 부정적인 리뷰를 할 가능성이 훨씬 더 높다는 오래된 속담과 일치합니다. 개인적으로 나는 다른 많은 것들 위에 작은 학습 곡선이 나타날 때마다 이 소품을 특별한 케이스에 넣는 것보다 훨씬 낫다고 생각합니다.

저는 그 주변에서 좀 더 민주주의적인 모습을 보고 싶다고 생각합니다. 이 매우 구체적인 변경은 위원회에서 수행할 수 있다고 생각합니다(본질적으로 이 변경을 고려하게 만든 것은 유사 위원회였습니다). 지는 쪽. 그것이 매일 최소한의 사람들에게 영향을 미치기 위해서입니다.

ps. 다른건 다 멋져요 btw 특히 이벤트 물건 👌🏻

새로운 업데이트를 기다리고 있습니다

@gaearon 자신의 예를 고려할 가치가 있습니까?

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div class={'something ' + rest.class} {...rest}/>
);

버그가 포함되어 있고 예상대로 작동하지 않습니까? "구조화하지 마세요"처럼 간단하지 않을 수도 있습니다.

클래스가 className인 것에 대해 걱정하지 않은 유일한 사람입니까? 어떤 문제가 반응하는지 나에게 묻는다면 내 마음을 결코 생각하지 않을 것입니다.

그래도 업데이트는 공짜이고 나는 공짜를 좋아합니다.

클래스가 className인 것에 대해 걱정하지 않은 유일한 사람입니까?

나는 수업에 대해 전혀 걱정하지 않는다. IE11의 미묘한 버그가 더 재미있을 것입니다(그래도 저는 이러한 변경 사항에 여전히 문제가 없습니다)

Passive Event Listeners 지원이 모바일의 중요한 기능인 React Fire의 범위 안에 있다면 좋을 것입니다. #6436

동의한다. 그것은 확실히 이 작업의 범위에 있습니다.

Hey @gaearon - 먼저 감사합니다.

사람들이 어떻게 반응하고 어떤 API가 사용되고 있으며 무엇이 혼란스러운지에 대한 정보를 수집하기 위해 설문조사를 하는 것을 고려해 본 적이 있습니까?

React는 지금까지 내가 가장 좋아하는 프론트엔드 개발 스택이지만 배우고 처음 사용할 때 몇 가지 발판이 있음을 알았습니다. 나는 내가 가르친 사람들이 개인적으로 혼란스러워하는 것을 단순히 나열하고 싶지 않습니다.

개인적으로 참여한 프로젝트(Node, Bluebird 등)에서 유용하다는 것을 알았습니다.

개인적으로 핵심에서 보고 싶은 것: 더 간단한 비전역 종속성 주입 지원, 더 우수하고 일관된 이벤트 처리(이미 논의 중인)를 원합니다.

사람들이 react >를 어떻게 사용하고 있으며 어떤 API가 사용되고 있으며 무엇이 혼란스러운지에 대한 정보를 수집하기 위해 설문조사를 수행하는 것을 고려해 본 적이 있습니까?

나는 react-native가 canny.io를 가지고 있다고 생각합니다. 나는 react가 그렇지 않다는 것을 깨닫지 못했습니다.

저는 모든 버전의 React를 15.4로 되돌리는 RMWC https://jamesmfriedman.github.io/rmwc/ 라는 UI 라이브러리를 유지 관리합니다. 통합 API 표면을 유지할 수 있었지만 className을 class로, onChange를 onInput으로 변경하고 이벤트 시스템을 정밀 검사하면 계속하기가 거의 불가능해집니다.

후드 아래에서 이 항목의 일부를 번역할 수 있는 "호환" 레이어의 가능성이 있습니까? 따라서 반응 화재가 어떤 버전이든 작성할 수 있지만 더 낮은 런타임에서 계속 실행됩니다.

나는 당신의 우려에 공감합니다(나는 또한 나의 공평한 몫의 라이브러리를 썼습니다). 그러나 무엇이든 변경하는 데에는 너무 많은 절충점이 있기 때문에 사람들이 여러 버전을 지원하도록 돕기보다는 사람들이 업그레이드하도록 돕는 데 노력을 기울이는 편에서 실수하는 경향이 있습니다. 이것은 우리 가 전혀 하지 않는다는 것을 의미하지는 않지만(16.3에서 라이프사이클 변경을 위해 라이브러리 작성자를 위한 폴리필을 출시했습니다) 이 사용 사례에 대해 최적화하지 않습니다.

내 제안은 무언가가 호환되지 않는 경우 새 전공을 자를 때 새 전공을 깎는 것입니다. 사람들은 원한다면 라이브러리의 이전 주요 버전을 계속 사용할 수 있습니다. 특히 계속 개발하는 경우 유지 관리에 더 많은 노력이 필요하다는 것을 압니다. 그러나 단일 해킹 코드베이스가 2개의 분기되지만 일관된 코드베이스보다 나은지 여부는 의심스럽습니다.

@jamesmfriedman codemod 를 사용하여 자동으로) 새 API로 업데이트한 다음 (빌드 프로세스의 일부로) (codemod를 사용하여) 이전 API로 변환하는 것이 가능해야 합니다(너무 복잡하지 않음). 그런 다음 두 번들을 모두 배송하고 React 버전에 따라 동적으로 요구합니다.

그것은 약간의 작업이지만 (예를 들어 webpack 플러그인이나 npm 설치 스크립트로?) 한 번만 수행할 수 있으며 어렵지 않아야 합니다. 나는 그것이 한 번 릴리스되고 모든 라이브러리에서 사용되는 종류의 것이라고 가정합니다.

특히 라이브러리를 위한 컴파일 시간 호환성 레이어와 같습니다.

for에 대한 htmlFor 삭제를 지원합니다.

className과 class를 모두 지원하는 브리지 릴리스가 좋은 생각이라고 생각하십니까? 이를 통해 개발자는 현재 자사 코드가 미래에 직면할 수 있는 동안 이전의 타사 React 코드를 사용할 수 있습니다. 타사 업데이트가 완료되면 완전히 최적화된 React DOM을 갖기 위해 브리지 패키지를 삭제하는 것만큼 쉽습니다.

React API는 일관성이 없고 추가 가정을 깨뜨립니다(htmlFor가 아닌 이유 등).

for 도 변경되어야 한다고 말했을 때 마지막 문장을 놓친 것 같습니다. 그런 다음 하나 또는 두 개의 드문 SVG 속성을 제외하고 "낙타 케이스 속성 이름"과 완전히 일치할 것이라고 생각합니다. 우리도 바꿀 수 있습니다.

전체 "class v className" / "for v htmlFor" 상황을 처리하는 Babel 플러그인이 없었나요?

나는 이것에 대한 꽤 많은 언급을 보았으므로 명확히하고 싶습니다. Babel 플러그인은 다음과 같은 경우에 작동하지 않기 때문에 이 변환을 수행하기에 좋은 장소가 아닙니다.

const props = {
   class: "foo"
}
<div {...props} />

또한 class 를 전달하지만 구성 요소의 소품에서 className 를 얻는 것도 이치에 맞지 않습니다. 또는 플러그인이 플랫폼 요소만 대상으로 했다면 button 를 Button 바꾸면 class 소품이 컴파일되는 대상이 변경되는 것이 이상합니다.

이를 위해 Babel 플러그인을 사용하면 작성 중인 코드의 의미가 모호해지고 더 많은 혼란이 야기됩니다. 제 생각에는 className 또는 class 만 허용하는 것보다 더 나쁜 솔루션입니다.

재미있는 사실: 이것이 JSX 컴파일러의 아주 오래된 버전이 작동하는 방식입니다. 이 동작은 혼란스럽기 때문에 제거되었습니다.

멋진 변화 . . .

놀라운! 이러한 흥미로운 업데이트를 제공하기 위해 노력한 모든 기여자에게 감사합니다.
className > class 가 이렇게 큰 스캔들인지 몰랐습니다. 개인적으로 익숙해졌습니다.

번들 크기 감소 및 이벤트 시스템 업그레이드는 정말 유망합니다. 슈퍼 스토킹!

이벤트 시스템의 폴리필을 별도의 패키지로 분리하는 것을 정말 기대하고 있습니다.
그러나 className > class가 너무 급진적이든 React는 너무 광범위한 영향을 미칩니다.
이로 인해 많은 시스템에서 예상치 못한 상황이 발생합니까?

React DOM의 1/3을 삭제하는 것이 좋습니다.

웹 앱 개발에서 React를 사용하면 좋을 것입니다.

key 및 ref $ 와 같은 특정 소품에 반응하는 네임스페이스도 좋을 것입니다. 예

<Foo @key="foo" @ref={callback} prop="hi" />

이것은 여기에서 논의되었습니다 - https://github.com/facebook/jsx/issues/66

@elado 우리가 미래에 하고 싶은 것일 수도 있지만 DOM에 특정하지 않은 API에 영향을 미치기 때문에 범위 밖이라고 생각합니다.

흥미롭긴 하지만 특히 번들 크기의 감소는 항상 환영합니다. 내 걱정은 Facebook 사람들이 API 변경을 깨는 관성, 고통 및 단편화가 생태계와 커뮤니티에 일으킬 수 있는 관성, 고통 및 단편화를 과소평가하고 있다는 것입니다.

그들이 FB에 걱정할 구성 요소가 많은 것은 사실이지만, 그들이 얻은 이점은 대부분의 구성 요소를 내부적으로 구축했을 가능성이 높기 때문에 외부 오픈 소스 반응 라이브러리에 대한 최소한의 종속성입니다. 많은 오픈 소스 라이브러리를 사용하는 다른 사람들의 경우 많은 라이브러리에서 Proptypes를 가져오는 데 많은 노력과 기다림과 좌절이 필요했습니다. 제한된 자원으로 안정적인 비즈니스를 구축하려는 사람들에게는 빠르게 움직이고 깨는 것이 적합하지 않을 수 있습니다.

나는 반응을 정말 즐깁니다. API는 간단하며 개인적으로 구문을 배우고 조정하는 데 시간이 걸리지 않았습니다. 따라서 나는 유지 관리자가 생태계 전반에 걸친 변경 사항의 장단점을 신중하게 평가하고 변경 사항이 전체 생태계를 다시 작성해야 하는 경우 실용적으로 생각할 것을 강력히 촉구합니다.

그 외에도 React를 구축, 유지 관리 및 업그레이드하는 노력과 그 뒤에있는 엔지니어의 열정에 정말 감사드립니다. :)

이 미래의 {...업데이트}는 🔥

className -> class : 클래스 속성이 JSX/객체 선언 외부에 정의되어 있는 경우는 드물지 않다고 생각합니다. 이러한 상황에서는 동일한 항목에 대해 다른 이름을 사용해야 하므로 불일치가 발생하고 코드 복잡성과 인지 부하가 ​​증가합니다.
제안된 변경 사항은 코드베이스에서 속성/소품 이름 불일치를 제거하지 않습니다. 구문 제한으로 인해 또는 기본 DOM으로 작업할 때 어딘가에 존재할 것입니다. 우리가 이 명명 문제에 대해 "표준화"된(그리고 이 시점에서 잘 확립된) 해결 방법을 만든 것은 좋은 일입니다.
현재 className 는 어디에서나 일관되게 사용할 수 있으며, 기본 DOM으로 작업할 때도 항상 같은 것을 참조합니다. 실제로 반응은 말 그대로 유일한 장소일 수 있습니다. 여기서 클래스 속성을 참조하기 위해 class 를 사용해야 합니다.
className 는 처음부터 상당히 불필요하고 약간 혼란스러워 보였지만 나중에는 상당히 실용적이고 비교적 익숙해지기 쉽습니다.

또한 dangerouslySetInnerHTML $에 대한 추가 개체 { __html } 는 정말 불필요해 보이기 때문에 제거하지만 마이그레이션과 관련된 문제는 가치가 없을 수도 있습니다(이 문제와 전혀 관련이 없을 수도 있음).

다른 변경 사항은 훨씬 적은 감정을 생성하지만 훨씬 더 흥미롭고 중요하므로 fb 팀의 노력에 감사드립니다.

주요 변경 사항이 많을수록 실제 사용자 응용 프로그램을 업그레이드하는 데 더 오래 걸립니다. 개인적으로 나는 이미 최신 React(슬프게도)에 한참 뒤쳐져 있습니다. 왜냐하면 이전 버전의 React는 업그레이드에 의존하는 라이브러리를 필요로 하는 문제를 깨뜨렸기 때문에 지연이 발생했습니다.

이상적으로는 다음과 같은 시나리오에 있고 싶습니다.

• 다운스트림 React 라이브러리는 새 버전에서 코드를 다시 작성하여 내 사용 사례에 대한 버그를 소개합니다.
• React는 멋진 새 기능/번들 감소를 추가합니다.
• 새 React에서 이전 라이브러리 버전을 계속 사용할 수 있습니다.
• 예, React 실행 직후 새 기능을 사용할 수 있으며 라이브러리에서 버그를 수정하기를 기다리면 됩니다.

실제로는 다음과 같습니다.

• 라이브러리가 코드를 다시 작성하여 버그가 발생함
• React는 새로운 주요 변경 사항을 릴리스합니다.
• 오래된 라이브러리는 더 이상 작동하지 않습니다
• 새 라이브러리는 결국 업데이트됩니다.
• 버그가 여전히 존재할 수 있음
• 나는 (Ken Wheeler의 말을 인용하자면) "새로운 인기"보다 오래된 React에 오랫동안 집착했습니다.
• 내가 슬퍼 :(

'배송 코드 관점'에서 보면 모든 주요 업그레이드는 모든 종속성을 업데이트하고, 모든 것을 다시 테스트한 다음, 해결 방법이 있는지 확인하기 위해 새로운 버그를 찾는 것과 관련된 성가신 기술적 부채의 거대한 조각이 됩니다. 치명적인 취약점이 없거나 무언가를 하는 것이 진정으로 비현실적이지 않는 한(그리고 그 기준이 높음) 우선 순위가 낮아집니다.

불행히도 0.x 패러다임을 벗어났음에도 불구하고 핵심 웹 라이브러리가 되려는 노력에도 불구하고 React는 여전히 버전 번호를 휘젓고 있습니다.

기본적으로 제가 말하고자 하는 바는 앞으로의 큰 변화가 깨지지 않도록 API를 계획해 보세요.

(또한 IE11은 EOL이 아닌 브라우저를 더 이상 사용하지 않기 때문에 슬픈 일입니다. 마지막 릴리스는 52일 전입니다. React 팀은 이것이 Facebook 팀과 모든 외부 및 내부 라이브러리 팀에 작업을 푸시하여 이를 완화한다는 것을 알게 될 것이라고 생각합니다. 대신에).

@urugator

나는 또한 실제로 불필요해 보이기 때문에 위험하게 SetInnerHTML에 대한 추가 객체 { __html }을 제거할 것입니다.

이것은 의도적으로 명시적이며 실수로 사용하기 어렵게 설계되었습니다. 제거된 경우 정제되지 않은 데이터가 실수로risklySetInnerHTML에 전달될 수 있습니다.

@philipwhiuk

기본적으로 제가 말하고자 하는 바는 앞으로의 큰 변화가 깨지지 않도록 API를 계획해 보세요.

주요 변경 사항은 기술을 개선하는 데 필요하며 React는 드물게 발생하는 주요 변경 사항을 책임감 있게 수행합니다. componentWillReceieveProps를 제거하는 것과 같은 주요 변경 사항이 없으면 React Suspense와 같은 훌륭한 기능을 사용할 수 없으며 커뮤니티의 소프트웨어는 이전 API가 영원히 유지되기 때문에 유지 관리하기가 더 어려워질 것입니다. 한 번에 하나의 주요 릴리스를 업그레이드하면 문제가 없습니다.

또한 IE11은 EOL이 아닌 브라우저를 더 이상 사용하지 않기 때문에 슬픈 일입니다. 마지막 릴리스는 52일 전입니다.

아무도 IE 11을 사용하지 않습니다. React의 현재 버전은 실제로 IE 11의 일부 기능에 대해 폴리필을 필요로 하므로 제안된 변경 사항은 IE 11 개발에 거의 동일한 영향을 미칠 것입니다. https://reactjs.org/docs/javascript-environment-requirements.html

나는 또한 실제로 불필요해 보이기 때문에 위험하게 SetInnerHTML에 대한 추가 객체 { __html }을 제거할 것입니다.

@urugator - Facebook 내부에서 가장 일반적으로 사용되는 __html 는 서버에서 렌더링된 HTML을 React 구성 요소 트리에 삽입하는 것입니다. 해당 사용 사례의 경우 서버 측에서 __html 개체를 구성하고 클라이언트 측에서 수행하는 것에 대한 린트 규칙이 있습니다. 서버 측에서는 XHP 를 __html 속성을 가진 개체로 직렬화하는 메서드가 있습니다. 이는 XHP가 JSX와 매우 유사하고(실제로 JSX의 주요 영감이 됨) XSS 보호 기능을 가지고 있기 때문에 어디에도 보안 허점을 도입하지 않도록 합니다.

기본적으로 __html 객체 는 어딘가 에서 삭제되었으며 DOM에 직접 삽입해도 안전한 HTML 문자열을 표시합니다. 원시 문자열은 처리하기가 더 어렵습니다. 누군가가 실수로 원시 사용자 입력을 반환했는지(따라서 XSS 구멍이 발생했는지) 삭제되었는지 어떻게 알 수 있습니까?

예, 대부분의 앱에 사용 사례가 많지 않아야 하고 사용 사례가 합리적으로 포함되어야 하기 때문에 의도적으로 사용하기 어렵습니다. 일반적으로 React 구성 요소에서 직접 __html 객체를 생성해서는 안 되며, 오히려 이를 반환하는 함수가 있어야 합니다(문서에서 createMarkup 함수를 사용하는 방법 참조: https://reactjs. org/docs/dom-elements.html#dangerouslysetinnerhtml)

내 걱정은 Facebook 사람들이 API 변경을 깨는 관성, 고통 및 단편화가 생태계와 커뮤니티에 일으킬 수 있는 관성, 고통 및 단편화를 과소평가하고 있다는 것입니다.

올려주셔서 감사합니다. 나는 당신이 어디에서 왔는지 완전히 이해합니다. 하지만 React 팀의 대부분의 사람들은 채용되기 전에 Facebook 외부에서 React를 직접 사용해 왔다는 점을 지적하고 싶습니다. 종종 대규모 애플리케이션에서 사용됩니다. 그래서 저는 이것이 우리가 오픈 소스 사용자에게 영향을 미치는 종류의 문제에 공감하는 데 도움이 된다고 생각합니다. 나는 2년 동안 React를 사용해 왔으며 예를 들어 부모/소유자 컨텍스트 전환으로 인한 단편화를 아주 잘 기억합니다. 핵심은 좋은 마이그레이션 전략을 세우는 것이었고 이는 위의 모든 변경 사항에도 동일하게 적용됩니다.

그들이 FB에 걱정할 구성 요소가 많은 것은 사실이지만, 그들이 얻은 이점은 대부분의 구성 요소를 내부적으로 구축했을 가능성이 높기 때문에 외부 오픈 소스 반응 라이브러리에 대한 최소한의 종속성입니다.

이것은 역사적으로 제품 개발 측면에서 사실이었습니다. 그러나 Yarn이 만들어지고 웹 리포지토리와 통합된 이후로 내부 도구 페이지에서 사용되는 타사 구성 요소의 수가 증가하는 것을 확인했습니다. 따라서 타사 패키지에서도 점진적인 마이그레이션 전략이 필요합니다.

다른 많은 회사와 달리 우리는 전체 코드베이스에서 동일한 버전의 React를 사용합니다. 따라서 우리에게는 고유한 과제도 있습니다(예: 일부 제품을 업그레이드하기 위해 "기다림"만 할 수 없음). 이것은 확실히 좋은 마이그레이션 전략을 갖고 스트레스 테스트 역할을 하도록 더 많은 압력을 가할 것입니다.

많은 오픈 소스 라이브러리를 사용하는 다른 사람들의 경우 많은 라이브러리에서 Proptypes를 가져오는 데 많은 노력과 기다림과 좌절이 필요했습니다. 제한된 자원으로 안정적인 비즈니스를 구축하려는 사람들에게는 빠르게 움직이고 깨는 것이 적합하지 않을 수 있습니다.

궁금한 점이 있으면 다음과 같은 코드가 있습니다.

React.PropTypes = require('prop-types')
React.createClass = require('create-react-class')

우리는 "깨끗한 슬레이트"로 완전히 마이그레이션할 여유가 없기 때문에 우리 코드베이스에 있습니다. 그러나 오늘날 React로 시작하는 사람들과 코드베이스의 더 현대적인 부분은 그 무게를 짊어질 필요가 없습니다. 이것이 우리가 그것에 대해 생각하는 방식입니다. 우리는 새로운 React 사용자를 위해 더 나은 기본값을 선택하고 싶지만 일부 부분이 해킹될 수 있더라도 우리 자신과 다른 모든 사람을 위해 좋은 마이그레이션 스토리를 갖고 싶습니다.

제가 충분히 명확하게 전달하지 못했을 수 있으므로 사과드립니다. 대규모 변경에는 타사 라이브러리를 업데이트하는 데 오랜 시간이 걸리고 다른 버전이 공존해야 할 수도 있다는 점 등을 고려하여 정교하고 잘 실행된 마이그레이션 전략이 필요합니다. 예를 들어 class 와 함께 계획은 하룻밤 사이에 바꾸는 것이 아닙니다. 우리가 그것을 하기를 원한다면 우리는 그것을 롤아웃하는 방법에 대해 현명하고 싶을 것입니다. 아마도 우리가 둘 다 허용하는 유예 기간 또는 도우미가 그것을 더 쉽게 할 수 있도록 한 다음 점진적으로 이전 이름을 단계적으로 없애는 것입니다. . 아직 구체적인 전략은 없지만 우리와 당신 모두를 위한 좋은 전략 없이는 변화가 불가능하다는 것은 분명합니다. 이것은 우리가 매우 심각하게 생각하는 것입니다.

(또한 IE11은 EOL이 아닌 브라우저를 더 이상 사용하지 않기 때문에 슬픈 일입니다. 마지막 릴리스는 52일 전입니다. React 팀은 이것이 Facebook 팀과 모든 외부 및 내부 라이브러리 팀에 작업을 푸시하여 이를 완화한다는 것을 알게 될 것이라고 생각합니다. 대신에).

나는 당신이 말하는 것을 이해하지 못합니다. 나는 IE11이 "더 이상 사용되지 않는다"고 말한 적이 없습니다.

내 게시물은 IE11과 같은 브라우저에 대해 지금보다 더 많은 폴리필이 필요할 수 있다고 말합니다. React 는 이미 IE11에서 일부 폴리필을 필요로 합니다 . 우리가 그것을 깨고 싶다는 말은 아닙니다. 여전히 많은 사용자가 있습니다. 그러나 작동하려면 더 많은 폴리필을 포함해야 합니다. 그것은 나에게 완전히 공정해 보인다.

또한 Facebook의 다른 팀에 "작업을 푸시"할 수 없습니다. 우리가 무언가를 깨뜨리면 그것을 고칠 책임이 있습니다. 이것이 바로 우리가 마이그레이션 전략에 많은 관심을 기울이는 이유입니다. 일반적으로 직접 실행해야 합니다.

Re: 귀하의 나머지 의견 — 우리는 그것을 위해 절대적인 변경을 하지 않습니다. 사실 우리는 변경 사항이 깨지는 것을 피하기 위해 매우 열심히 노력하고 있습니다. React에는 복잡하고 유지 관리하기 어려운 많은 부분이 있지만 명시적으로 불안정한 것으로 표시된 경우에도 레거시 API를 지원하려는 유일한 이유 때문에 유지합니다. 그러나 어느 순간 문제의 무게가 쌓이고 앞으로 나아가고 수정하기 위해 슬레이트를 청소해야 합니다. 내 OP 게시물의 문제는 정확히 그런 종류의 문제입니다. 혼자서는 획기적인 변경을 수행할 가치가 없습니다. 그러나 결합하여 우리는 그들이 노력할 가치가 있다고 생각합니다.

왜 사람들이 이것에 대해 부정적인지 이해가 되지 않습니다. 종속성이 업그레이드될 때까지 업그레이드하지 않습니까?

class vs className 및 for vs htmlFor 에 대한 키워드 문제는 jsx 컴파일러가 예약어를 재정의하기 위해 처리할 수 있는 문제가 아닙니까?

검색 결과가 쓸모없는 답변을 제공할 만큼 변경 사항이 충분히 큰 경우에만 정말 걱정할 것입니다... "angular -angularjs -angular1.x" 등을 인터넷 검색할 때 도입된 고통 angular 2+와 같이

그 외에는 모든 변경 사항을 환영합니다!!!

@gaearon

당신은 말했다

"일부 이전 브라우저와의 호환성을 삭제해야 할 수도 있습니다."

다음 polyfill 부분이 아니라 문제가 있었던 드롭 호환성 부분이었습니다. 암흑기로 돌아가는 것이 내 걱정거리였다.

프로세스에 관해서. 이러한 종류의 '문제'가 RFC 프로세스가 설계된 목적이 아닙니까?

다음 polyfill 부분이 아니라 문제가 있었던 드롭 호환성 부분이었습니다. 암흑기로 돌아가는 것이 내 걱정거리였다.

IE10 및 이전 버전에 대해 이야기했습니다. 저는 특히 IE11을 계속 지원하고 싶다고 말했습니다. 트래픽의 약 3%를 차지한다고 생각합니다. 이는 너무 오래된 것으로 간주되는 1% 컷오프보다 훨씬 많습니다.

프로세스에 관해서. 이러한 종류의 '문제'가 RFC 프로세스가 설계된 목적이 아닙니까?

더 구체화되면 RFC를 게시할 예정입니다. 이것의 대부분은 우리가 할 수 있는 것과 할 수 없는 것과 사용할 수 있는 마이그레이션 전략을 결정하기 위해 탐색, 실험 및 실제 테스트가 필요합니다. RFC(포괄적인 마이그레이션 전략이 포함되어야 함)에 대해 생각하기 시작하기에 충분한 세부 정보가 지금 없습니다.

네, 설명 감사합니다!

@gaearon

합성 이벤트를 완전히 제거할 가능성이 있습니다.

이벤트 리스너가 연결된 요소를 가리키는 event.currentTarget 에서 어떻게 작동할까요? 기본 경우에는 항상 document 를 의미합니다. 또는 React가 해당 요소로 전환되면 React 루트를 의미합니까?

React는 단순히 속성을 설정하는 것이 아닙니다.

(...)

여기서 내 요점은 React가 내부적으로 속성을 사용하는지 속성을 사용하는지 여부는 구현 세부 사항이라는 것입니다.

DOM에서 일어나는 일에 영향을 줄 수 있는데 왜 이것이 구현 세부사항입니까? class / className 와 같은 속성에 어떻게든 반영되는 속성만 참조하지 않는 한.

class / className 처리에 대한 혼란은 React가 속성을 사용하는지 속성을 사용하는지 여부를 구현 세부 사항으로 간주한다는 사실과 관련이 있다고 생각합니다. 나는 Angular 배경을 가지고 있고 React를 사용하기 시작했을 때 가장 큰 문제였습니다. Angular에서 속성, 속성 및 이벤트 핸들러 사이의 분리는 구문에서 직접 명확하고 DOM 요소의 props가 React에 의해 다음과 같이 설정되었는지 여부가 혼란스러웠습니다. 속성 또는 속성.

이벤트 리스너가 연결된 요소를 가리키는 event.currentTarget과 어떻게 작동할까요? 네이티브의 경우 항상 문서를 의미하거나 React가 해당 요소로 전환되면 React 루트를 의미합니까?

나는 아직 모른다. :-) 우리는 우리가 무엇을 할 수 있는지 볼 것입니다. 이 중 일부가 제대로 작동하지 않거나 다르게 나타날 가능성이 있습니다. 이 계획은 우리가 검토할 계획의 대략적인 개요와 통합 비전입니다.

DOM에서 일어나는 일에 영향을 줄 수 있는데 왜 이것이 구현 세부사항입니까? 그것이 class/className과 같은 속성에 어떻게든 반영되는 속성만 참조하지 않는 한.

대부분의 경우 사용자의 관점에서 어떤 것을 사용할지 관찰할 수 있는 차이가 없습니다. 나는 그것들의 대부분이 반영된다고 생각합니다(비록 내가 틀릴 수도 있지만).

나는 Angular 배경을 가지고 있으며 React를 사용하기 시작했을 때 가장 큰 문제였습니다. Angular에서 속성, 속성 및 이벤트 핸들러 간의 분리는 구문에서 직접 명확하고 DOM 요소의 props가 React에 의해 속성으로 설정되었는지 여부가 혼란스러웠습니다. 또는 속성.

나는 당신의 관점에 감사드립니다. 그러나 실제로 이 차이는 대부분의 DOM 요소와 관련 이 없는 경우가 많으며 어떤 요소를 사용해야 하는지, 그리고 항상 그것에 대해 생각해야 하는 것을 배우는 것이 일상적인 제품 개발에 실제로 가치가 있다는 점에 대해서는 논쟁의 여지가 있습니다. 사람들이 그들을 혼동하는 정도는 실제로 그들과 그다지 관련이 없다는 사실을 말해주는 것 같아요.

(사용자 정의 요소와 같이 훨씬 더 관련성 이 높아지는 경우가 있습니다. 그러나 거기에서도 둘 다 똑같이 지원하는 것은 사용할 것을 선택해야 하기 때문에 혼란스럽습니다. 이것은 다른 곳에서 논의되었으므로 점프를 피하고 싶습니다. 이 토론에 다시 참여하십시오 — @robdodson 과 같은 사람들로부터 제안이 있으며 우리는 그것들을 조사할 것입니다.)

@다니엘15
언급된 정책(다른 곳에서는 언급되지 않은 것 같습니다)이 없으면 추가 개체 래퍼가 어떤 식으로든 보안을 유지하지 못합니다.
나는 사용자가 dangerouslySetInnerHTML 를 통해 위험한 사용에 대해 충분히 경고했다고 생각합니다. 그것이 사용자 si가 문서를 확인하고 의미를 고려하고 결정을 내려야 했던 시점입니다.
(아마도 정제되지 않은) 문자열을 객체/함수로 래핑할 필요가 있다고 해서 래핑된 값을 재고하거나 삭제하지 않을 것입니다.
그런 식으로 작동한다면 아마도 { __html } 가 충분히 복잡하지 않고 [{ _html: { __html }] 가 훨씬 더 안전할 것입니다. 안전을 위해 무언가가 위험하다는 것을 몇 번이나 말해야 합니다. ?

당신이 제공한 통찰력으로 나는 그 추론을 이해하지만, 우리는 " { __html } 가 정화된 html을 나타냄" 규칙에 대한 단서가 없기 때문에 현재 페이스북 외부의 누구에게도 적용되지 않는다고 생각합니다.
나는 항상 그것이 API의 또 다른 장애물이라고 생각했습니다. 시간을 할애해 주셔서 감사합니다. 이제 좀 더 이해가 됩니다.

단순히 복잡하게 만드는 것이 아니라 삭제되지 않은 데이터가 우발적으로 사용되는 것을 방지하는 것입니다.

나는 단지 반응이 커뮤니티에서 그렇게 독단적인 방식을 좋아합니다. 이 모든 것을 듣고 최대한 활용해 주셔서 감사합니다.

나는 모든 사람들이 여기에 오고 있거나 마지막 버전에서 React에 적용된 변경 사항이 '중단'이라고 생각하는 방식을 좋아합니다. 그 사람들은 분명히 Angular 2 > 3 > 4번을 경험하지 않았습니다.

나는 변화를 사랑한다. 개인적으로 나는 className 에 신경 쓰지 않고 class 를 구조화하는 것이 번거로울 수 있습니다. 그러나 나는 너희들이 무엇을 생각해 낼지 보고 싶다.

이 토론을 계속 주제로 하고 싶습니다. 위험한 HTML을 오염시키는 것이 도움이 되는지 여부는 흥미롭지만 문제와 관련이 없습니다.

나는 리액트를 사랑한다

이것은 새로운 개발자가 더 환영받는다고 느끼도록 도울 수 있는 완벽한 기회입니다. 이런 일이 일어나서 매우 기쁩니다.

사람들이 클래스를 사용하도록 허용하는 것은 구조화 및 마이그레이션 비용과 함께 작동하지 않는다는 점을 제외하고는 부정적인 영향이 없습니다.

@gaearon 2c를 던지지만 이 두 가지 부정은 현재 부정보다 크거나 커 보입니다(일회성 학습 클래스의 작은 비용 => className 대 항상 구조화 방지 + 생태계 수준 마이그레이션 비용).

반응:심장:

위의 @natew 를 반향:

@gaearon 2c를 던지지만 이 두 가지 부정은 현재 부정보다 크거나 커 보입니다(일회성 학습 클래스의 작은 비용 => className 대 항상 구조화 방지 + 생태계 수준 마이그레이션 비용).

어쨌든 className 에서 class 로 변경한 동기는 무엇입니까?
내가 알 수 있는 한 귀하의 의견은 두 가지 주장으로 요약됩니다.

대부분의 사람들이 기대하는 것과 개념적으로 더 가깝습니다.

좋습니다. 하지만 Name 를 추가하는 것은 가장 작은 장애물입니다. className 사용법을 배우는 것은 React를 배우는 가장 간단한 부분이었습니다. 단점이 없는 작은 단점입니다. 실제로는 4개의 캐릭터로 문제를 해결합니다. 그리고 제공되는 어떤 분해 대안보다 인지 오버헤드가 훨씬 적습니다.
누군가에게 첫 번째 React 구성 요소의 스타일을 지정하는 방법을 가르치는 것을 상상해 보세요.

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

내 멍청한 머리가 폭발했을 것입니다.
API와 상호 작용할 때 사람들은 API가 솔루션을 제공하기를 기대한다고 생각합니다. ClassName은 기본 제공 솔루션입니다. 클래스는 기본 제공 문제입니다.

적은 타이핑

헐 4글자 8^) . 게다가, 우리가 현재 className 를 사용하는 것보다 훨씬 덜 자주 class 를 구조화하더라도 우리가 할 때 훨씬 더 많은 타이핑을 합니다. 그래서 저는 4개의 문자를 12번 더 입력했지만 class 을 분해할 때마다 50개의 문자를 더 추가했습니다. 이것은 단지 어리석은 일입니다.

내가 놓친 이 변경 사항에 대한 또 다른 강력한 이유가 있습니까?
동기가 DOM 속성/속성 준수에 대한 일종의 우려입니까?
그것은 나에게 너무 학문적인 주장처럼 보입니다. 대부분의 사람들은 이러한 구현 세부 사항을 잘 알지 못하며 그럴 필요가 없다고 생각합니다.

오늘 출시되면 React는 className으로 변경하는 대신 class 를 허용합니까?
나는 그것이 관련이 없다고 생각한다.
React는 현재 오픈 소스가 아니었으며 1년 후에 오픈 소스로 제공된다면 그 당시 다른 결정이 내려질 수 있습니다.
때로는 모든 주름을 다림질하는 것보다 일관성을 유지하는 것이 좋습니다.

그리고 React가 처음부터 클래스를 사용했다면 우리는 클래스를 구조화하고 이를 className에 재할당하는 데 익숙해졌을 것입니다.

마지막으로 제 자신이 이 일로 이렇게 화를 낼 줄은 몰랐기에 무례하거나 모욕적이거나 비방하는 내용이 있었다면 사과드립니다. 나는 당신이 React에서 하는 모든 일과 Twitter에서 제공하는 모든 지식에 감사드립니다. 인터뷰에서 내가 제공한 몇 가지 답변을 변호하기 위해 당신의 트윗을 사용했습니다.

마음이 바뀌기를 dan.church 에 기도합니다.

react를 지속적으로 업그레이드할 수 있어서 매우 기쁩니다. react를 사용하는 개발자로서 vue에 추월당하는 것을 보고 싶지 않습니다. 그러나 className-> class의 과정은 고통스러울 것입니다.

나는 복사-붙여넣기를 위해 className -> class 이름을 바꾸는 것에 반대하지 않지만 현재로서는 명확한 동기가 없습니다. className 는 DOM에 존재하지만 htmlFor 와 같이 아무데도 나오지 않는 예약된 prop 이름이 있습니다. 이름을 바꿀 때 우선 순위를 지정해야 하고 테스트 역할을 할 수 있는 변경 사항에 덜 퍼진 것 같습니다.

@sonhanguyen htmlFor는 공식 웹 API 이름이기도 합니다. https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

@allan2coder 배열로 래핑하는 대신 <React.Fragment> 또는 <> 로 래핑합니다.

@allan2coder 또한 이 스레드를 주제로 유지하십시오. 원하는 경우 별도의 문제를 제출하여 질문할 수 있습니다.

의존성을 패치하기 쉽게 만드는 패키지인 patch-package 에 주의를 기울이고 싶습니다(예: 지원되지 않는 React API 사용을 중지하기 위해). 확실히 이것은 라이브러리 코드보다 애플리케이션 코드에 더 유용하지만 @philipwhiuk 의 우려 사항 중 일부를 해결하는 데 도움이 될 것이라고 생각합니다.

기대하고 있어요.

• onChange에서 onInput으로 마이그레이션하고 제어되지 않는 구성 요소에 대해 폴리필하지 마십시오.

위 단어의 경우 onChange 이벤트를 네이티브 이벤트에 가깝게 사용하거나 앞으로 사용하지 않을지 궁금합니다.

@무윤윤

문구에 따르면 onChange의 현재 동작을 유지할 계획이 없습니다. 별로 의미가 없을 것입니다. 다른 최신 라이브러리와 마찬가지로 React는 브라우저 호환성 레이어가 아니며 그렇게 되어서도 안 됩니다.

현재 onChange는 입력 + 몇 가지 다른 경우를 에뮬레이트합니다. 변경 이벤트가 이미 DOM에 존재하고 동일한 의미를 갖지 않는다는 점을 고려하면 전혀 의미가 없습니다: https://developer.mozilla.org/en-US/docs/Web/Events/change

@jxub

약간 오프탑이지만 (내가 아는 한) 아무도 HTML 속성을 매핑하는 사소한 변경으로 React로의 마이그레이션을 쉽게 하기 위해 html/css/svg -> jsx 변환기를 만들 생각을 하지 않았다는 것은 다소 슬픈 일입니다. 리액트 소품. 대부분 찾기 및 교체를 수행하는 데 많은 시간이 낭비되었습니다.:(

다른 편집기에 대해서는 모르지만 IntelliJ IDEA(및 WebStorm, PhpStorm 등)는 HTML 코드를 JS에 붙여넣을 때 이 변환을 수행합니다.

약간 오프탑이지만 (내가 아는 한) 아무도 HTML 속성을 매핑하는 사소한 변경으로 React로의 마이그레이션을 쉽게 하기 위해 html/css/svg -> jsx 변환기를 만들 생각을 하지 않았다는 것은 다소 슬픈 일입니다. 리액트 소품. 대부분 찾기 및 교체를 수행하는 데 많은 시간이 낭비되었습니다.:(

실제로 존재하지만 꽤 오래되었고 완전히 정확하지는 않습니다. https://magic.reactjs.net/htmltojsx.htm

우리는 그 노력을 되살려야 합니다. 도움이 필요하면 https://github.com/reactjs/reactjs.org/issues/484를 수행하십시오. 지금까지 아무도 도와주겠다고 제안하고 후속 조치를 취하지 않았습니다.

실제로 존재하지만 꽤 오래되었고 완전히 정확하지는 않습니다. https://magic.reactjs.net/htmltojsx.htm

저는 이것을 전에도 많이 사용했습니다. HTML/CSS는 알지만 JavaScript는 모르는 사람들에게 특정 구성 요소를 아웃소싱할 때 사용하는 것이 매우 일반적입니다.

따라서 이것이 사람들이 실제로 사용하는 유용한 도구라는 피드백을 제공하는 것입니다. 온라인에 다른 변환기도 있습니다.

이 접근 방식의 문제는 단방향(반응으로만 마이그레이션)이라는 것입니다. 하지만 그 문제는 React에만 있는 것은 아닙니다.

일이 훨씬 쉬워지길 바랍니다...

이 접근 방식의 문제는 단방향(반응하기 위해 마이그레이션만)이라는 것입니다. 하지만 그 문제는 React에만 있는 것은 아닙니다.

왜요? 그 반대의 경우 훨씬 더 쉬워야 합니다. ReactDOMServer.renderToString 를 실행하면 됩니다.

릴리스를 참을성 있게 기다리고 있습니다.

@gaearon

왜요? 그 반대의 경우 훨씬 쉬워야 합니다. ReactDOMServer.renderToString을 실행하기만 하면 됩니다.

네, 문맥상 논의된 문제는 다음과 같습니다. html/css를 작성하고 JavaScript를 잘 모르는 사람들이 구성 요소의 마크업/스타일/레이아웃에서 작업할 수 있도록 JS 코드에서 작업할 수 있기를 바랍니다.

지금 당장 할 수 있는 한 가지 방법은 html/css로 개발하고 htmltojsx를 사용하도록 하는 것입니다. 그것은 나를 위해 꽤 잘 작동합니다.

문제는 이제 React에서 모든 마크업/스타일/레이아웃 변경을 직접 유지해야 한다는 것입니다.

ReactDOMServer.renderToString 를 호출하면 실제로 정적 HTML을 얻을 수 있지만 해당 HTML에는 모든 실제 구성 요소 코드가 누락되어 UI 사용자에게 제공하고 출력을 사용하는 것은 불가능합니다. 내 논리.

react-sketchapp과 같은 것은 문제를 해결할 수 있는 좋은 방법이지만 일반 html/css를 사용하는 동안 이 작업을 수행할 수 있는 보다 일반적인 접근 방식을 원합니다. 예를 들어 - 일부 형태의 메타데이터를 통해 요소에 반응 ID를 유지합니다.

나는 이것이 ReactDOM 코어의 범위에 속하지 않는다는 것을 완전히 이해하지만 확실히 그 영역에 있고 흥미로운 문제입니다.

이것은 높은 우선 순위가 아닙니다. 저는 주로 htmltojsx가 마이그레이션 컨텍스트 외부에서도 우리 중 일부에게 유용한 이유를 설명하고 싶었습니다. :)

html/css를 작성하고 JavaScript를 잘 모르는 사람들이 JS 코드에서 작업할 만큼 충분히 구성 요소의 마크업/스타일/레이아웃에서 작업할 수 있기를 바랍니다.

이것은 얼마나 큰 문제이며, 그들에게 약간의 JSX를 가르치는 것이 얼마나 어려울까요? 어쨌든 변경 사항은 React에 정통한 엔지니어가 검토해야 합니다.

너무 주제를 벗어나면 죄송하지만 요즘에는 HTML/CSS만으로는 충분하지 않다고 생각합니다.

( @gaearon 위의 이미 약간의 OT 댓글에 대한 답변이므로 시끄럽다면 숨길 수 있습니다.)

이것은 얼마나 큰 문제이며, 그들에게 약간의 JSX를 가르치는 것이 얼마나 어려울까요? 어쨌든 변경 사항은 React에 정통한 엔지니어가 검토해야 합니다.

글쎄, 그것은 다음이 필요합니다:

• 현재 React 스택에 익숙한 계약자와만 작업하십시오. styled-components를 배울 사람들을 찾는 것이 훨씬 더 어렵습니다.
• Node(npm), 스택(React, webpack 등) 및 이를 실행하는 데 필요한 모든 것을 UI 사용자의 컴퓨터 각각에 설치하고 최신 상태로 유지합니다.
• 그들에게 몇 가지 기본 프로그래밍과 JavaScript를 가르치고 devtools, 콘솔 오류 등으로 작업하는 방법을 배우십시오.
• React, 구문이 무엇인지, className , key 의미 등을 가르쳐주세요.
• HTML/CSS를 생성하기 보다는 그러한 방식으로 작업하고자 하는 계약자 및 프리랜서와만 작업하십시오. 이것은 일반적으로 물건을 더 비싸게 만듭니다.

이제 위에서 언급한 것처럼 react-skeptchapp과 같은 것은 UI 사용자가 이를 더 쉽게 접근할 수 있도록 하는 유용한 방법이지만 여전히 많은 것을 배워야 합니다.

나는 당신이 이것을 묻는 이유를 완전히 이해하고 이것이 일반적인 문제인지 확신하지 못합니다 (나는 의심됩니다). 어쨌든 나는 그것이 ReactDOM의 핵심의 미래를 위한 범위라고 생각하지 않습니다.

이것은 주제에서 벗어났습니다 :-) 트위터나 다른 곳에서 이 토론을 계속합시다.

"도구가 사용되는 것을 보는 행동은 도구가 권장하는 행동입니다"
~ 게리 번하트

React가 사용되는 방식은 대부분이 React API의 일부가 아니기 때문에 모두가 혼란스러워하고 좌절하는 이와 같은 토론을 초래하는 많은 함정을 초래합니다. class 와 같은 예약 키워드를 사용하는 것이 javascript, html 또는 react 자체 때문에 나쁜 것입니까?

16.3에서 변경된 사항으로 돌아가서(제 기억이 맞다면) 라이브러리는 이제 vdom에 의해 렌더링되는 기본 html 요소에 전달된 모든 속성을 수락하여 다르게 작동합니다. 우리가 이 명백히 나쁜 패턴 을 구현한 행동의

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

그래서 나는 Dan이 우리가 이 끔찍한 코드를 모든 코드베이스에 계속 퍼뜨릴 것을 제안한다는 사실에 상당히 실망했다고 말하고 싶습니다.

우선, props 의 내용에 대한 보장은 없지만 처음에는 기본 html 요소에 잘못된 소품을 전달하면 거의 항상 예상대로 작동하지 않습니다. 그러나 동시에 부모 소품을 자식 구성 요소로 전파하는 것이 안전한 것으로 간주되지만 실제로는 매우 게으릅니다.

<Child {...props} />

const Child = (props) => <div {...props} />

때때로 당신은 당신이 무엇을 렌더링하고 있는지조차 알지 못하며 이 문제는 다루기가 훨씬 더 어려워집니다. 또한 유형 시스템을 사용하여 이러한 종류의 구성 요소를 유형 검사하는 것은 매우 어렵습니다. 이는 대부분의 구성 요소가 서로 공유해야 하는 여러 임의 인터페이스를 구현해야 한다는 것을 의미하기 때문에 깊이 들어갈 수 있는 토끼굴입니다.

이 문제를 수정하기 위해 반응을 다시 작성하면 잘못된 결정을 두 배로 줄이는 대신 이러한 나쁜 패턴이 코드베이스에 미치는 피해를 그 뒤에 있는 디자이너가 깨달을 것으로 기대합니다.

우리는 jsx가 자바스크립트 위에 구축되었다는 것을 기억해야 합니다. 그리고 자바스크립트의 "특이성"을 키워드 사용에서 의도적으로 언어와 충돌하기 위한 핑계로 사용하는 것은 API를 수정하기 위한 나쁜 첫 번째 단계입니다. 전쟁을 시작하는 대신 제안하고 싶습니다 언어에 대해 완전히 멀리 이동할 것입니다.

@gaearon 오랜만 ! :) (ps. 죄송합니다 tl;dr 앞으로)

어쨌든, 저는 제 자신의 모험에서 배운 것에 대한 통찰력을 제공하고 싶었습니다. 성능/기능에 중요한 응용 프로그램에 사용하는 나만의 "최소한의" React 파생물을 만들었습니다. 처음에는 그저 재미있는 실험이었지만 다른 많은 이점을 포함하여 초기 렌더링/업데이트/삭제에 대한 실제 사례에서 +300% 이상의 성능 향상을 보았습니다. 풀링된 이벤트 핸들러도 사용하지 않는 것입니다.

IIRC의 많은 부분은 모든 React-props 로직을 우회하고 단순히 속성을 setAttribute에 직접, 스타일을 style.setProperty에 직접, 리스너를 addEventListener에 직접 공급하는 등의 방식으로 내 라이브러리에서 가져온 것입니다. 따라서 기본 DOM 요소 인터페이스는 `{attributes: {}, style: {}, listeners: {}, className: "", ...}와 같이 보입니다. 더 장황하지만 인터페이스는 이제 작고 구현하기 쉽고 간단합니다. 매우 빠릅니다. 이것은 아마도 당신에게 너무 극단적일 것입니다. 그러나 그것은 저에게 아주 잘 도움이 되었습니다.

내가 하고 있는 것은 CSS를 완전히 삭제하는 것입니다. 모든 스타일은 인라인입니다. 예상보다 훨씬 빠르며 많은 실용적인 이점이 있습니다. 또한 브라우저 초기 CSS 구문 분석(놀랍게도 비쌈) 및 대부분의 오버헤드를 회수하는 선택기 일치 비용을 피할 수 있습니다. 전력이 부족한 노트북에서도 복잡한 계층 구조(나무 가지치기 없이)에서 안정적인 60FPS와 그 이상을 쉽게 달성할 수 있습니다.

나는 그 대부분이 당신에게 실제로 유용하지 않다고 생각하지만 아마도 거기에 흥미로운 것이 있을 것입니다. 어쨌든 HTML+React에 대한 나의 주요 불만은 React 사용자 구성 요소가 CSS에 의존하지 않고 레이아웃/포지셔닝(그리고 아마도 어느 정도 이벤트)을 위한 인터페이스를 노출하지 않는다는 것입니다. 간단히 말해서 ButtonComponent를 만든 다음 사용하면 기본적으로 배치되거나 레이아웃에 통합될 수 없습니다. 내부에 목적 특수 로직을 구현하고, 배치할 수 있는 더미 요소로 래핑하거나 ButtonComponent 루트 요소에 사용되는 스타일에 병합되는 스타일 소품을 노출합니다. 그 중 어느 것도 완벽하지 않으며 스타일을 있는 그대로 병합하면 안 되는 스타일을 쉽게 넣을 수 있으므로 위험합니다. 본질적으로 문제는 구성 요소 경계에서 사용 가능한 속성의 하위 집합이 공개(위치 지정/레이아웃)이고 일부는 내부(시각적 스타일 지정)여야 한다는 것입니다.

내가 하는 또 다른 일은 구성 요소와 콘텐츠/자식을 분리하는 것입니다. 예를 들어 DOM 구성 요소는 자식 목록을 사용하지 않고 대신 콘텐츠 인스턴스를 허용합니다. 콘텐츠 인스턴스는 조정 논리와 자식 렌더링을 구현하므로 목적에 따라 다른 구현을 가질 수 있습니다. 가장 명백한 사용 사례는 다음과 같습니다. 대부분 정적 계층 대 동적으로 생성된 자식. 따라서 대다수를 구성하는 정적 계층 구조는 더 빠른 간단한 논리를 사용하여 구현할 수 있는 반면 동적으로 생성된 자식은 구성 가능한 전략을 가질 수 있습니다. 또한 불필요한 간접 참조 없이 플렉스박스 레이아웃을 지능적으로 관리하는 데 사용할 수 있는 "컨텐츠 구성 요소"를 가질 수 있는 가능성을 열어줍니다.

그와 관련하여 React가 잘못되었다고 생각하는 것은 어린이이며 아직 구체적인 결론이나 솔루션에 도달하지 못했습니다. 하지만 두 지점 사이의 모든 단일 요소를 다시 렌더링하지 않고 루트에서 임의의 지점으로 소품을 버블링할 수 없고 효과적으로 가지치기도 종종 문제가 된다는 점에서 React에 근본적인 문제가 있다고 강력히 믿습니다. 성능은 대부분 "충분히 양호"하며 React에서 이를 관리하는 복잡성이 추가되어 해결할 가치가 없을 수 있습니다. 그러나 지금까지의 실험에서 나는 아주 적은 양의 사소한 코드로 전체 루트 업데이트 비용을 단순한 분수로 줄일 수 있었지만 내 직관은 그것이 React의 철학이나 단순한 자식 모델과 그다지 호환되지 않는다고 말합니다.

대부분 당신을 위한 것은 아니지만 내 라이브러리의 큰 특징은 기본적으로 범용으로 최소한의 "기본 DOM 요소"만 제공한다는 것입니다. 특정 요구 사항/상황이 있는 대규모 프로젝트를 매우 저렴하게 개발하고 "해킹"에 의존하지 않고 자신의 저수준 특정 동작을 사소하게 확장/교체하고 구현할 수 있다는 아이디어입니다. -지향성, 특별한 스타일 처리 등 ). 이것은 또한 모든 것을 포괄하고 모든 사람의 문제를 해결하려고 노력할 필요 없이 DOM 요소 인터페이스에서 상당히 독단적일 수 있음을 의미합니다.

여하튼, 아마도 대부분은 그저 떠돌아다니는 것이고 나는 아마도 대부분의 개념을 잘 전달하지 못할 것입니다. 그러나 아마도 반대 방향으로 갔던 누군가로부터 당신을 위한 흥미로운 정보가 있을 것입니다. 당신이 "단순함"을 목표로 하고 있기 때문에 대부분은 아마도 당신과 관련이 없을 것입니다. 하지만 누가 알겠습니까? :)

또한 내가 잊기 전에 내 objectKeyValueReconcile 함수에 관심이 있을 수 있습니다. 특히 React와 유사한 시나리오의 prev/next props를 비교하는 데 매우 빠르도록 최적화되어 있습니다. 그것은 저에게 상당한 실제 성능 향상에 대한 책임이 있습니다.

https://github.com/syranide/surgical/blob/master/packages/surgical/private/objectKeyValueReconcile.js

imho 나는 "클래스"아이디어를 떨어 뜨릴 것입니다. JSX는 결국 죽을 것입니다.

요소 기반이 아닌 DOM/창 이벤트에 대한 지원을 React DOM에 추가하는 것에 대한 생각은 무엇입니까? 합성 이벤트를 제거할 수 있으면서도 이벤트 수집/업데이트/일괄 처리의 일부 형태가 여전히 있을 것이라고 생각합니다. 키 누르기, 크기 조정 및 창 스크롤 이벤트는 일반적으로 생각나는 시나리오이지만 https://developer.mozilla.org/en-US/docs/Web/Events 에 있는 대부분의/모든 목록을 지원할 수 있다면 동일한 추상화 뒤에 유용합니다.

이것은 가장 오래된 공개 문제 #285 😄에서도 논의됩니다.

@gaearon

className -> class 의 실제 효과는 다음과 같습니다.

({ className }) => <div className={className} />

될 것입니다

({ ...rest }) => <div class={rest.class} />

이점은 전적으로 학문적 이지만 이 변경은 상당한 고통을 야기할 것입니다. 우리는 다른 커뮤니티에서 비슷한 일을 하는 것을 보았습니다. 예를 들어 python3 가 10년 전에 처음 출시되었으며 우리는 여전히 이에 대해 논쟁하고 있습니다. 커뮤니티의 상당 부분이 전환을 하지 않았고 앞으로도 하지 않을 것입니다. 다시 생각해 주세요.

@kans

아니면 이거:

props => <div class={props.class} />

원래 기능과 비슷한 복잡성입니다.

class는 js의 키워드이기 때문에 className이 마음에 들었지만 어느 쪽이든 그렇게 큰 문제는 아니라고 생각합니다. 글래머러스한 스타일링을 선호하기 때문에 영향을 받는 부분은 아니다. 나는 아마도 지난 몇 년 동안 className을 수십 번 사용했을 것입니다?? 거의 없다.

class 에 찬성하는 한 가지 생각은 실제로 className을 사용하는 대부분의 사람들이 css를 사용하고 있으며 class 의 html/css 모델을 기대한다는 것입니다. 이 prop의 압도적인 주요 목적은 실제로 css 코드와 연결하는 것입니다. 그렇다면 html/css 사용자가 기대하는 것처럼 클래스라고 부르지 않는 이유는 무엇입니까?

디자인 시스템 코드 외부의 IMO, 정말 관용적인 React 개발은 일반적으로 어쨌든 className 또는 class를 많이 사용하지 않습니다. CSS용 클래스를 사용해야 하는 경우 대부분 몇 가지 작은 UI 구성 요소에 격리됩니다. 애플리케이션 계층에서 사용되는 거의 모든 것이 더 높은 수준입니다(예: <Columns verticalAlign="center"> 또는 <BodyText /> ).

그래서 className 에서 class 로 이름을 바꾸면 어쨌든 prop을 사용하는 사람들이 더 쉽게 (React 개발에 참여하고 컨텍스트를 전환하고 화를 내지 않는지 궁금합니다. 등), 이름을 바꾸지 않는 이유는 무엇입니까?

묶음 크기를 줄이십시오.

이것은 크고 중요한 업데이트이므로 React 수명 주기 이름도 수정할 수 있습니다!

예를 들어 shouldComponentUpdate => shouldUpdate 등. 이 이름은 어리석은 것이 아닙니다.

@AlexGalays

이것은 크고 중요한 업데이트이므로 React 수명 주기 이름도 수정할 수 있습니다!

즉 shouldComponentUpdate => shouldUpdate 등. 이 명명은 어리석은 일을 넘어선 것입니다.

더 긴 수명 주기 후크 이름은 검색 시 덜 모호합니다. 더 짧은 이름은 너무 일반적이고 해당 이름이 위치한 컨텍스트에 따라 다르므로 우연히 다른 대규모 코드베이스와 일치할 수 있습니다(가양성 일치).

수명 주기 메서드는 React 코어의 일부이며 이 문제는 전적으로 react-dom에 관한 것입니다.

@ljharb
정말이지!

@sompylasar
죄송합니다. 그것은 단순히 좋은 이유가 아닙니다(말장난 의도, reasonReact가 메서드 이름을 수정했습니다 :)). 우리는 패키지 이름으로 모든 모듈에 접두사를 붙이지 않고 잘 찾습니다. 어쨌든, react-core는 이 문제의 범위를 벗어났기 때문에 이에 대한 이야기는 그만하겠습니다.

이러한 변화를 보고 싶습니다.
맞춤 요소 상호 운용성을 염두에 두고 구현되기를 바랍니다.

토론의 일부를 포럼(https://discuss.reactjs.org)에서 별도의 스레드로 옮길 가치가 있는지 궁금합니다. GitHub 문제는 포럼 게시물처럼 스레드되지 않기 때문에 동일한 문제에서 여러 가지를 논의하기가 까다롭습니다.

className -> class 의 변경 사항이 흥미롭게 보입니다 😺

2019년 React 프로젝트 보기

const {
  class: className, // YouKnowIamRight PepeHands
  someFancyProp,
  ...restProps
} = props

나는 이것이 확실히 오는 것을 본다.

HTML을 복사하여 붙여넣을 수 있고 className 를 변경할 필요가 없는 것을 정말 좋아하지만 동시에 class 예약 키워드가 가져올 수 있는 문제를 보고 있습니다.

이 시점에서 저는 className에 대해 강한 엔지니어링 문제가 없는 한 className 를 고수하는 것을 선호합니다(개인 취향이 아님).

그러나 그것은 나의 실용적인 생각일 뿐입니다.

class 식별자를 파괴할 수 없다는 추가적인 마찰을 이해하지만, 이 스레드의 너무 많은 사람들이 클래스 이름을 소품으로 받아야 하는 횟수를 과대평가하는 것 같습니다.

className 를 React 구성 요소(단순한 DOM 요소가 아님)에 전달한다는 것은 새로운 추상화를 제공하지 않고 아주 작은 빌딩 블록을 만들거나 해당 구성 요소가 구현 세부 사항의 일부를 노출한다는 것을 의미합니다. 첫 번째 경우(예: <Button /> 구성요소) 에서는 @gaearon 의 예제를 따르고 props의 "나머지"도 DOM 요소로 전달하고 싶을 것입니다. 두 번째 경우에는 추가 마찰로 인해 작업을 피하고 더 나은 솔루션을 찾게 될 수 있습니다.

내 겸손한 경험에서, 나는 className 받는 구성 요소를 만든 것을 기억할 수 있는 것보다 더 많이 JSX에 붙여넣기 HTML을 복사해야 했습니다( class 를 className 로 대체).

모든 소품을 HTML로 퍼뜨리는 것은 안티 패턴입니다. 미래에 누군가가 HTML 속성과 일치하는 추가 소품을 포함하면 예기치 않게 동작이 변경됩니다. IE가 새 속성을 추가하면 호스가 잡힙니다.

@philipwhiuk 사용하지 않는 소품만 퍼뜨리면 행동 문제가 발생하지 않습니다.

@j-f1

사용하지 않는 소품만 퍼뜨리면 행동 문제가 발생하지 않습니다.

설마. 구성 요소 API에 새 옵션을 추가하면 이 옵션이 기본 DOM 노드로 전달되지 않습니다. 누군가는 요소에 설정된 정확한 속성에 의존할 수 있으며 그런 다음 그 사람을 깨뜨릴 수 있습니다. 사용하지 않는 모든 props를 아래의 모든 항목에 퍼뜨리는 것은 구성 요소 API에 추가되는 모든 것이 주요 변경 사항임을 의미합니다.

Btw, class 의 값을 분해하지만 그 세부 사항에서 잘리지 않는 임의의 예를 사용했습니다.

많은 분들이 (그렇습니다) 추가 텍스트 입력을 피하는 것 외에 다른 이유 없이 점 표기법을 사용하는 대신 props 및 state 에서 거의 모든 값을 분해합니다.

그래서 제가 상황을 강조하고 있지만, 옆으로 치우쳐서 소품을 퍼뜨리는 데 초점을 맞추거나 그것에 대해 이야기할 수 있는 다른 측면 주제에 초점을 맞추지 마십시오.

좀 더 실용적이라면 개인적인 선호도 대신 기술적 의미에 대해 이야기하겠지만 className 의 기술적 의미에 대해 말하는 사람은 아무도 없습니다.

주의해야 할 또 다른 사항은 핵심 기여자가 개인 취향의 문제에 초점을 맞추도록 한다는 것입니다.

그들의 시간, 노력 및 돈(회사에서)은 커뮤니티가 우리의 관심을 집중할 더 나은 것들이 있다는 것을 이해하고 Core 팀의 누군가가 우리가 선호하는 것에 한 시간을 할애할 수 있다는 것을 이해하면 더 좋습니다. React의 다음으로 중요한 것은 이러한 변경에 대한 리팩토링 코드가 없다는 것입니다.

그러나 다시, 나의 실용적인 의견.

폴리필에 대해 말하자면, 반응이 사용자가 "좋은" 폴리필을 지정했는지 여부를 감지해야 한다고 생각하지 않습니다.
(예: 코드에서 hasBadMapPolyfill )
React는 프로그래밍 프로젝트에서 저지를 수 있는 모든 무작위 실수에 대해 책임을 지지 않아야 합니다.

@AlexGalays React는 올바른 의미 체계로 Map 구현을 사용하는 것에 의존합니다. 사용자가 비준수 폴리필을 사용하는 경우 앱이 예상치 못한 혼란스러운 방식으로 중단될 수 있으므로 이 경우 미리 경고하는 것이 도움이 됩니다.

이것은 개발 빌드에서만 수행되므로 프로덕션에서 이에 대한 오버헤드가 없습니다.

저는 이 React Fire를 좋아하고 ReactDOM을 현대화하는 더 흥미로운 단계인 것 같아서 계속 작업할 것입니다.

반응 발사가 이벤트 핸들러를 리바인드하지 않을 수 있습니까?

class Compo exntends Compoent {
 onClick() {
   ...
 }
  render() {
   <button onClick={this.onClick} >click me </button>
  }
}

이벤트 핸들러가 리바운드되기를 원하는 사람은 아무도 없다고 생각합니다. 드문 경우지만 수동으로 바인딩할 수 있습니다.

@cullophid

반응 발사가 이벤트 핸들러를 리바인드하지 않을 수 있습니까?

화살표 함수 자동 바인딩을 사용하거나 생성자에서 함수를 바인딩하여 메서드를 클래스에 한 번 바인딩할 수 있습니다. 이벤트에 연결하려는 고유한 매개변수가 있는 경우 이벤트 핸들러를 메모화하거나 DOM 속성을 노드 자체에 연결하고 event.currentTarget 를 통해 액세스할 수 있습니다.

class Compo extends Compoent {
 onClick = () => {
   ...
 }
 render() {
   <button onClick={this.onClick}>click me</button>
 }
}

이벤트 시스템을 단순화하는 또 다른 이점(모든 프레임워크처럼 풀링 없이 원시 DOM 이벤트로 돌아갈 수 있습니까? :))은 정적으로 입력하는 것이 더 쉽다는 것입니다.

좋은 계획인 것 같습니다! IE 11 지원이 있으면 정말 좋을 것입니다(완전히 괜찮은 자체 폴리필을 제공하는 것을 의미하더라도). 정부 고객과 함께 일하는 사람으로서 IE 11 사용을 중단할 시기는 완전히 알 수 없습니다.

@MatthewHerbst 같은 보트, 우리 고객은 IE 11을 사용하고 트래픽이 충분합니다 😢

이 모든 것이 매우 흥미롭다는 말을 하고 싶었습니다. 내가 읽은 한 가지 걱정스러운 점은 다음과 같습니다.

기존 브라우저의 차이점 중 일부를 부드럽게 하려고 시도하지 않을 수 있습니다.

지금은 React의 이벤트 시스템이 React가 지원하는 모든 브라우저에서 "그냥 작동"한다는 사실을 알고 싶습니다. 이 변경으로 인해 브라우저 간 문제를 설명하는 것은 앱의 책임이 될 것입니다. 이렇게 하면 추적하기 어려운 버그가 많이 발생할 수 있습니다. ...적어도 내 앱에서는 그럴 것입니다. :)

어쨌든 좋은 도서관에 항상 감사드립니다.

@kentcdodds 는 내가 전략 을 읽고 있던 가능한 아이디어로 JSX 2.0 통합을 언급했지만 이와 관련된 것으로 보이는 것을 보지 못했습니다. 그것이 단지 공중에 떠 있는 것인지 아니면 미래를 위해 보류될 것인지 궁금합니다.

IE가 죽게하십시오! 완전히 오래된 브라우저를 지원하지 마십시오. 제한적인 회사라도 최신 브라우저로 전환하지 않을 이유가 없습니다. 귀하와 웹이 지원을 중단할 때까지 통계에 IE11이 표시됩니다.

@hbroer 레거시 소프트웨어?

@hbroer 아무도 자신의 사이트가 여전히 작동하기 때문에 이전 브라우저에 머물지 않고 선택의 여지가 없거나 업데이트 방법을 모르기 때문에 그렇게 합니다. 이러한 사용자를 위한 사이트를 깨는 것은 극도로 적대적이며 업데이트된 브라우저가 아니라 아무것도 남기지 않습니다.

• "업데이트 방법을 모릅니다" - 우리의 문제는 아니지만 브라우저 목록과 함께 "새 브라우저 설치" 메시지를 입력할 수 있습니다. 도움말 텍스트와 Microsoft 핫라인 전화번호도 함께 입력할 수 있습니다 ^^
• "선택의 여지가 없다" - 맞습니다. 하지만 조직은 환경을 업데이트해야 합니다. 그들의 도구가 작동하지 않으면 작동합니다.

나는 과거를 위해 코딩하는 것을 싫어하고 새로운 기술의 이점을 사용할 수 없습니다. 코더의 90%가 여전히 지난 세기에 살고 있는 하위 15% 소비자의 형편없는 브라우저를 지원하기 때문입니다. ^^ 앞으로 10년 동안 "아 이 인터넷 익스플로러 6 멍청이가 뭐야, 우리는 그 15%를 지원해야 한다"라는 말을 다시 듣고 싶지 않습니다.

btw M$ 솔기는 Windows 7 및 8용 Edge를 웹킷으로 전환하여 가져옵니다.

@hbroer 사용자에게 영향을 미치는 경우 모든 것이 우리의 문제입니다. 다른 사람에 대한 약간의 공감을 가지세요.

(따로, M$ 는 아주 어리고 매우 오래된 90년대 후반 참조이므로 제거하고 싶을 수 있습니다. 제거할 경우 제쳐두고 기쁘게 생각합니다.)

여기 많은 M$ 팬 보이즈가 있습니다. :DI는 정말로 인간에 관심이 있지만 기술 발전을 방해하는 조직이나 오랜 세월에 걸쳐 그 오래된 쓰레기를 지원해야 하는 코더에는 관심이 없습니다. 라이브러리를 "오래된 쓰레기와 호환 가능"하게 만드는 추가 패키지에는 문제가 없습니다. 그러나 2019년의 라이브러리는 <=2013 기술이 아니라 >=2019 기술을 염두에 두고 코딩해야 합니다. 사파리와 (오래된) 에지 쓰레기를 지원해야 하는 것은 충분히 나쁜 일입니다.

마이크

@hbroer 사실 고대 안드로이드 브라우저와 고대 사파리는 어떤 마이크로소프트 브라우저보다 더 큰 문제입니다. 그것은 "fanboi"가 되는 것이 아니라 전문적이 되는 것에 관한 것이며 "M$"라는 용어를 사용하는 것은 아닙니다.

그리고 아니요. 오래된 기술을 지원하는 것은 어떤 식으로든 "나쁜" 것이 아니라 도덕적이고 윤리적인 일입니다. 나쁜 점은 Netscape Navigator, IE 6, 최신 Chrome 등 "X에서 가장 잘 작동하는" 웹사이트입니다.

여기 많은 M$ 팬 보이즈가 있습니다.

@hbroer 여기에서 전면 광고 인신공격을 하는 사람을 봅니다.

그러나 2019년의 라이브러리는 <=2013 기술이 아니라 >=2019 기술을 염두에 두고 코딩해야 합니다.

아니, 그러면 안 된다.

1초 정도 시간을 내어 브라우저 목록 기본값을 살펴본다면 놀랄 것입니다. 대신에, 당신은 인신공격과 학교 식당 수준의 모욕에 의존합니다.

사용자가 충분하면 IE11은 웹사이트에 액세스하는 상당한 규모의 사람들이 됩니다. 이전 직장에서 우리는 IE11에서 한 달에 백만 명에 가까운 사람들이 우리 웹사이트에 액세스했습니다.

오래된 쓰레기를 지원하려면 폴리 채우기를 추가하십시오. 미래와 현재를 위해 코딩하지 않을 이유가 없습니다. 오래된 기술을 지원하면 웹 앱이 필요 이상으로 뚱뚱해지고 느려집니다.

ps. 비꼬는거 못읽고 웃는거 신경안쓰는 사람이 보이네요^^

@hbroer 당신은 IE11이 존재한다는 것을 보여주고 있습니다. 그래서 우리는 그것을 코딩할 것으로 예상됩니다.

그리고, 다시 한 번. https://browserl.ist 에서 기본값 을 참조하십시오.

ps. 비꼬는거 못읽고 웃는거 신경안쓰는 사람이 보이네요^^

예, 아닙니다. 이것은 트롤과 놀이터에서 괴롭히는 사람들이 사용하는 일반적인 전술입니다. "뭐라고?! 욕한게 아니야! 농담이었어!"

"인터넷을 사용하는 사람들"로 필터링하더라도 지구상의 사람들의 0.20%는 640만 명입니다. 백분율은 전혀 관련이 없습니다. 인간을 위한 코드; 과거와 미래, 번들 크기는 중요하지 않습니다.

브라우저 호환성과 마찬가지로 인간 번들 크기에 맞게 코딩하려는 경우 확실히 중요합니다. 사용자는 일이 제대로 작동할 것으로 예상할 뿐만 아니라 로드 속도도 빨라야 합니다.

이제 2019년에 새 프로젝트에 CSS 그리드(IE11에서만 실험적 지원이 있음)를 사용하고 ES6으로 변환하고 오래된 브라우저에 대한 폴리필을 제공하고 싶지 않습니다. IE11 사용자는 단순히 다음과 같은 메시지를 받습니다. 브라우저를 업데이트하거나 다른 브라우저를 사용하십시오.

자바 스크립트를 사용하고 싶지 않은 사람들이 있습니다. 당신은 그들을 걱정합니까? 당신은 통계에서 그 사람들을 볼 수 없습니다. 그리고 저 역시 그 도구를 차단하는 다른 많은 사람들처럼 통계 분야에 있지 않습니다.

나는 구식이 아닌 모든 브라우저를 주시합니다. 나는 Windows 7(2020년 1월 말 지원) 때문에 IE11 쓰레기보다 사용자가 적은 edge를 지원하고 현대인은 최신 브라우저를 사용합니다. ^^

폴리필이나 호환성 패키지 같은 것을 사용하는 것을 막는 사람은 없습니다. 그러나 핵심은 최신 상태여야 하며 오래된 M$ 기술 브라우저의 한 부분 때문에 뒤쳐져 있어서는 안 됩니다.

많은 자바스크립트 프레임워크에서 내가 놓치고 있는 것은 LTS입니다. 그것이 우리가 이야기할 수 있는 것입니다. 현재의 기능으로 최신 페이지를 구축한다면 최신 기술 프레임워크를 사용하는 것이 좋습니다. 그리고 최대의 안정성과 호환성이 필요한 b2b용 웹앱을 구축하는 경우 LTS 버전을 사용할 수 있습니다. 또는 녹아웃을 사용합니다. 그러면 아직 업데이트되지 않은 Windows XP와 IE6을 함께 사용하는 소수의 100t를 지원할 수 있습니다^^

호환성은 원본 게시물의 "절충안" 아래에 명확하게 나열되어 있으므로 이전 브라우저를 완벽하게 지원하는 것은 이미 두 번째 초점입니다.

지원해야 하는 경우 더 많은 폴리필과 통합이 필요하지만 그렇게 하기 위한 선택 이 될 것입니다. 또한 다른 브라우저 대상에 대해 여러 번들을 만들고 각 방문자에 대해 가능한 가장 작은 JS를 제공하여 전체 청중에게 영향을 미치지 않도록 할 수 있습니다.

React Fire 자체의 진행 상황은 영향을 받지 않은 것 같으므로 이 토론에서 얻을 수 있는 것은 없습니다. 계속 진행하고 본론으로 돌아가자.

#6410을 해결할 좋은 기회가 아닐까요? onChange / onInput 에 제안된 변경 사항과 영향이 비슷해 보입니다.

2019년 6월 5일 업데이트

오랜만이야. 여기 우리의 위치에 대한 작은 업데이트가 있습니다.

우리는 12월에 Fire 작업을 시작했습니다. https://github.com/facebook/react/pull/14382 및 기타 스레드에서 일부 작업이 진행 중입니다. 그러나 불필요하거나 구식이라고 생각되는 이벤트 시스템의 일부를 제거하기 시작하면서 최신 브라우저에서도 매우 유용하고 버그를 방지하는 많은 엣지 케이스를 발견했습니다. 우리는 여전히 레거시 팽창을 줄이고 싶지만 원시 DOM 이벤트에 더 가까이 가는 것이 실제로 가장 좋은 방향인지는 분명하지 않습니다. 애플리케이션 코드에 라이브러리 코드를 여러 번 다시 추가하기 위해 줄이는 것은 최선의 절충안이 아닙니다. 그리고 앱 수준에서 문제를 해결하는 것이 항상 가능한 것도 아닙니다.

이와는 별도로 FB5 작업을 하는 동안 React를 사용하는 경우에도 마우스와 터치 장치 모두에서 작동하고 느낌이 좋은 사용자 인터페이스를 구현하는 데 상당한 어려움이 있음을 깨달았습니다. onClick 와 같은 이벤트를 사용할 때 버튼과 같은 기본적인 것들도 마우스와 터치로 매우 다르게 느껴지며, 호버, 포커스 등으로 일관된 동작을 달성하기가 훨씬 더 어려워집니다.

그래서 Fire 작업을 시작할 때 커스텀 이벤트 시스템이 필요하지 않다고 생각했습니다. 그러나 그것을 제거한 프로토타입 후, 우리는 우리의 이벤트 시스템이 실제로 이러한 일련의 문제를 해결하기 위한 가장 큰 수단이라는 것을 깨달았습니다.

이 조사의 결과, React Fire의 일부인 다른 항목에 대한 작업을 일시적으로 중단하고 먼저 이벤트 시스템에만 집중하기로 결정했습니다. 그 프로젝트는 React Flare(https://github.com/facebook/react/issues/15257)로 알려지게 되었습니다. 그 자체로 충분히 도전적이며 이 목록의 다른 항목에 영향을 미치므로 먼저 단독으로 집중하고 있습니다.

React Flare의 목표는 데스크톱과 모바일에서 마우스와 터치를 사용하여 액세스할 수 있는 멋진 UI를 쉽게 구축할 수 있도록 하는 것입니다. 여기에는 Press, Hover 및 Focus와 같은 상호 작용을 관리하기 위한 선언적 API가 포함됩니다. 현재 React 이벤트 시스템과 달리 Flare 디자인은 사용하지 않는 이벤트에 대해 번들을 팽창시키지 않으며 마우스 및 터치 이벤트를 처리하는 UI 라이브러리의 코드 양을 줄일 수 있어야 합니다.

React Flare는 아직 실험 단계이지만 전반적인 방향에 대해 상당히 확신하고 있으며 결국 공식적으로 오픈 소스에서 사용할 수 있도록 할 계획입니다. (지금은 마스터에서 수동으로 빌드하는 경우에만 작동하며, 현재 작업 중이므로 semver 보장이 없습니다.) Fire와 마찬가지로 "Flare"는 코드명일 뿐입니다. 적절한 명명, 문서 등. 아마도 react/events 또는 이와 유사한 것입니다. 우리는 결국 React Native에서도 동등한 이벤트를 제공하고 싶습니다.

React Flare의 초기 구현을 마친 후에는 React Fire 목록으로 돌아가서 배운 내용을 사용하여 다른 모든 사항을 재평가할 것입니다. Flare가 "풍부한" 이벤트 집합을 인수하면 React DOM에서 "기본" 이벤트 처리를 단순화하고 많은 폴리필을 제거할 수 있습니다. 지금까지 토론에 참여해 주신 모든 분들께 감사드리며 이 정보가 유용하기를 바랍니다.

훌륭한 일! 따라서 이벤트 시스템은 마우스와 터치 이벤트의 균형을 유지하는 데 여전히 필요하지만 가볍고 React와 독립적입니다.

"React Flare"가 기본 React 패키지의 일부로 제공되거나 함께 제공될 API의 양을 고려하여 추가 설치가 필요합니까?

사용하지 않는 코드가 번들되는 것을 방지하고 싶습니다. 따라서 현재 의도는 API별로 옵트인하는 것입니다. 단일 패키지에 별도의 진입점이 있을 수 있습니다.

이 마우스 및 터치 이벤트 시스템이 PointerEvent 를 활용합니까? 이전 업데이트에서 이 웹 표준에 대한 언급을 본 적이 없으므로 주의를 환기시키고 싶었습니다.

포인터 이벤트는 포인팅 장치에 대해 실행되는 DOM 이벤트입니다. 마우스, 펜/스타일러스 또는 터치(하나 이상의 손가락)와 같은 포인팅 입력 장치를 처리하기 위해 단일 DOM 이벤트 모델을 생성하도록 설계되었습니다. 포인터는 특정 화면 좌표 집합을 대상으로 할 수 있는 하드웨어에 구애받지 않는 장치입니다. 포인터에 대한 단일 이벤트 모델을 사용하면 웹 사이트 및 응용 프로그램 생성을 단순화하고 사용자의 하드웨어에 관계없이 우수한 사용자 경험을 제공할 수 있습니다.

그리고 여기에 현재 브라우저 호환성 에 대한 직접 링크가 있습니다.

@jonathantneal 예, 새 시스템은 포인터 이벤트를 많이 사용합니다. 포인터 이벤트를 지원하지 않을 때 마우스/터치 이벤트로 대체합니다.

https://github.com/facebook/react/issues/11347 이 이 문제에서 해결되지 않은 것이 걱정됩니다. React는 https://custom-elements-everywhere.com을 폭로합니다.

이벤트 시스템을 재설계할 때 섀도우 루트를 고려하십시오. React 루트에 연결하는 것만으로는 오늘날 대부분의 문제가 해결되지 않고 요소에만 연결됩니다(https://github.com/facebook/react/issues/9242, https:// github.com/facebook/react/issues/15759, https://github.com/facebook/react/issues/13713, https://github.com/facebook/react/issues/11827)

이 업데이트에서: https://github.com/facebook/react/issues/13525#issuecomment -499196939 @gaearon 언급:

그러나 불필요하거나 구식이라고 생각되는 이벤트 시스템의 일부를 제거하기 시작하면서 최신 브라우저에서도 매우 유용하고 버그를 방지하는 많은 엣지 케이스를 발견했습니다.

이러한 엣지 케이스의 목록이 어디에나 문서화되어 있는지 궁금했습니다.

@gaearon 이제 Flare가 나갔고 (SCNR), 업데이트된 계획( 2019년 6월 5일 업데이트 관련)이 어떻게 진행되나요?

그리고 @trusktr 과 마찬가지로 여기에서도 #11347을 처리하고 싶습니다.

폴리필을 다른 번들, 특히 주요 에버그린 브라우저와 관련이 없는 번들로 분할할 수 있습니다.

안녕하세요, 오랜 시간이 흘렀고 우리는 이러한 것들을 켜고 끄기 위해 시도했습니다.

각각에 대해 업데이트하겠습니다.

• value 속성의 입력 값 반영을 중지합니다(https://github.com/facebook/react/issues/11896). 이것은 원래 https://github.com/facebook/react/pull/6406을 통해 React 15.2.0에 추가되었습니다. 사람들의 DOM 개념적 모델이 DOM 검사기에서 보는 value 가 value JSX 속성과 일치해야 하기 때문에 매우 일반적으로 요청되었습니다. 그러나 DOM이 작동하는 방식은 그렇지 않습니다. 필드에 입력할 때 브라우저는 value 속성을 업데이트하지 않습니다. React도 하면 안 됩니다. 이 변경은 CSS 선택기에 의존하는 일부 코드에 도움이 될 수 있지만 일련의 버그를 일으켰습니다. 그 중 일부는 여전히 수정되지 않았습니다. 이 변경으로 인한 일부 결과는 다음과 같습니다. https://github.com/facebook/react/issues/7179 , https://github.com/facebook/react/issues/8395 , https://github.com/facebook /react/issues/7328 , https://github.com/facebook/react/issues/7233 , https://github.com/facebook/react/issues/11881 , https://github.com/facebook/react /issues/7253 , https://github.com/facebook/react/pull/9584 , https://github.com/facebook/react/pull/9806 , https://github.com/facebook/react/pull /9714 ​​, https://github.com/facebook/react/pull/11534 , https://github.com/facebook/react/pull/11746 , https://github.com/facebook/react/pull/12925 . 이 시점에서 브라우저와 계속 싸우는 것은 분명히 가치가 없으며 되돌려야 합니다. 이 여정의 긍정적인 부분은 DOM 기여자( @nhunzaker , @aweary , @jquense 및 @philipp-spiess)의 지칠 줄 모르는 작업 덕분에 이제 회귀를 방지하는 데 도움이 되는 상세한 DOM 테스트 고정 장치를 갖게 되었다는 것입니다.

우리는 여전히 이것을 하기를 원하지만 이 목록의 다음 항목에 집중할 수 있도록 최소한의 가능한 주요 변경 사항을 갖도록 React 17을 "예약" 하기로 결정했습니다. 따라서 이 변경 사항은 React 18까지 대기합니다.

• 문서가 아닌 React 루트에 이벤트를 첨부합니다(https://github.com/facebook/react/issues/2043). 문서에 이벤트 핸들러를 연결하는 것은 React 앱을 더 큰 시스템에 포함할 때 문제가 됩니다. Atom 편집기는 이와 충돌한 첫 번째 사례 중 하나였습니다. 모든 대형 웹사이트는 결국 stopPropagation 가 비 React 코드와 상호 작용하거나 React 루트(https://github.com/facebook/react/issues/8693, https://github)에서 상호 작용하는 것과 관련된 매우 복잡한 엣지 케이스를 개발합니다. .com/facebook/react/pull/8117, https://github.com/facebook/react/issues/12518). 또한 업데이트 중에 런타임 검사를 덜 수행할 수 있도록 모든 루트에 열심히 이벤트를 첨부하려고 합니다.

우리는 이것을 React 17에서 하고 있습니다. 이것은 엄청난 작업 덩어리로 판명되었지만 고맙게도 완료되었습니다.

• onChange 에서 onInput 로 마이그레이션하고 제어되지 않는 구성 요소에 대해 폴리필하지 마십시오(https://github.com/facebook/react/issues/9657). 자세한 계획은 링크된 문제를 참조하세요. React가 DOM에서 input 이벤트라고 하는 이벤트에 대해 다른 이벤트 이름을 사용한다는 것은 혼란스러웠습니다. 우리는 일반적으로 큰 이점 없이 이와 같은 큰 변경을 피하지만, 이 경우 제어 입력을 변경하는 것과 같은 엣지 케이스에만 필요한 일부 복잡성을 제거하기 위해 동작 을 변경하고자 합니다. 따라서 이 두 가지 변경을 함께 수행하고 이를 기회로 사용하여 onInput 및 onChange 가 제어되지 않는 구성 요소에 대해 DOM 이벤트가 수행하는 것과 정확히 동일하게 작동하도록 합니다.

우리는 아마도 이것으로 돌아올 것입니다. 그러나 여기서 얼마나 많은 이탈이 가치가 있는지는 불분명합니다. 그래서 이것은 아직 미정입니다.

• 이벤트 시스템을 대폭 간소화합니다(https://github.com/facebook/react/issues/4751). 현재 이벤트 시스템은 2013년 처음 구현된 이후 거의 변경되지 않았습니다. React DOM 및 React Native에서 재사용되므로 불필요하게 추상적입니다. 제공하는 많은 폴리필은 최신 브라우저에 필요하지 않으며 일부는 해결하는 것보다 더 많은 문제를 생성합니다. 또한 React DOM 번들 크기의 상당 부분을 차지합니다. 여기에 아주 구체적인 계획이 있는 것은 아니지만 이벤트 시스템을 완전히 분기한 다음 DOM이 제공하는 것에 더 가까이 다가가면 얼마나 최소한으로 만들 수 있는지 확인할 것입니다. 합성 이벤트를 완전히 제거할 가능성이 있습니다. DOM에서 버블링되지 않고 버블링할 타당한 이유가 없는 미디어 이벤트와 같은 버블링 이벤트를 중지해야 합니다. 포털을 통한 버블링과 같은 일부 React 관련 기능을 유지하기를 원하지만 더 간단한 수단(예: 이벤트 재전송)을 통해 이를 수행하려고 합니다. 수동적인 이벤트가 이것의 일부가 될 것입니다.

우리는 2019년 초에 이것을 시도했고 진정으로 최소한의 이벤트 시스템은 내부 테스트에서 잘 작동하지 않았습니다. React가 하고 있는 브라우저 간 정규화 작업은 여전히 ​​오래된 브라우저를 사용하는 사람들이나 contentEditable 를 사용하는 리치 텍스트 입력 편집기와 같은 틈새 영역에서 유용합니다. 즉, 이벤트를 루트에 연결하는 작업의 일부로 이벤트 시스템에서 많은 추상화를 제거하여 향후 더 쉽게 이해하고 개선할 수 있습니다. React 17의 일부로 많은 혼란을 야기한 "이벤트 풀링"을 제거하고 더 이상 onScroll 이벤트를 버블링하지 않습니다. React 18에서 미디어 이벤트의 버블링을 중지하여 React 동작을 브라우저에 더 가깝게 만들 것입니다. 우리는 새로운 이벤트 시스템으로 약간의 바이트를 절약했지만 우리가 작업 중인 새로운 기능에 의해 사용되었으므로 전체적으로 번들 크기 감소로 이어지지는 않을 것입니다.

• className → class (https://github.com/facebook/react/issues/4331, https://github.com/facebook/react/issues/13525#issuecomment- 참조) 417818906 아래). 이것은 수없이 제안되었습니다. 우리는 이미 class 를 React 16에서 DOM 노드로 전달하는 것을 허용하고 있습니다. 이것이 생성하는 혼란은 보호하려는 구문 제한의 가치가 없습니다. 우리는 이 변경을 자체적으로 수행하지 않을 것이지만 위의 다른 모든 것과 결합하는 것이 합리적입니다. 구성 요소 생태계가 처리하기가 매우 어렵기 때문에 경고 없이 둘 다 허용할 수는 없습니다. 각 구성 요소는 둘 다 올바르게 처리하는 방법을 배워야 하며 충돌할 위험이 있습니다. 많은 구성 요소가 className 를 처리하므로(예: 추가하여) 오류가 발생하기 쉽습니다.

이것은 제안서에서 가장 논쟁의 여지가 있는 부분이었습니다. 그 이후로 우리는 함수 컴포넌트 작성을 권장하는 Hooks를 출시했습니다. 함수 구성 요소에서는 일반적으로 props에 대해 구조 해제를 사용하는 것이 좋지만 구문 오류가 발생하므로 { class, ... } 를 작성할 수 없습니다. 따라서 전반적으로 이것이 실제로 수행하기에 충분히 인체 공학적인지 명확하지 않습니다. 나는 우리가 미래에 이것을 다시 방문하거나 최소한 class 를 경고하지 않고 사람들이 원하는 것을 하도록 하는 것이 그럴듯하다고 생각합니다. 그러나 지금은 이 아이디어를 보류할 것입니다.

안녕하세요, 좋은 기사입니다!
React-DOM 제품 크기를 줄이기 위한 파이프라인 계획이 있는지 알고 싶었습니까? 모바일 애플리케이션의 경우 브라우저가 100KB 이상의 React-DOM JS 및 기타 모듈을 구문 분석하므로 여전히 오버헤드입니다. 그런 다음 앱별 JS.
콘텐츠가 풍부한 페이지의 경우 더 큰 차단 및 더 큰 TTI가 발생합니다.

우리는 언제 그러한 변화를 볼 수 있습니까?

@morevolk-latei 측정 시 100KB의 ReactDOM을 구문 분석하는 데 얼마나 많은 시간이 소요됩니까?