これ大好き。 バンドルサイズの縮小と「クラス」プロップは、非常に歓迎される変更です。

すごい仕事！

🙂

図書館の作者に注目！ 🤣

すごい！

className→クラスは素晴らしいです

他のすべてはどうですか？ まだclipPath 、 htmlFor 、 tabIndexなどを実行しているのは奇妙に思えます。

classを採用することは、ライブラリを初心者にとってより使いやすいものにするための大きな進歩です。 おめでとう。

これは素晴らしいです。 classへの移行が実際に小道具でどのように機能するのか非常に興味があります。

({ class }) => <div class={class} />は最初に予約キーワードの問題を提示するように思われますか？

これは素晴らしいニュースです、@ gaearonに感謝します！

classNameの変更を除いて、これらすべてのポイントが大好きです。 他のポイントが追求している目標（DOM APIとの整合性）とはまったく矛盾しているようです。 Reactは、HTML属性ではなく、DOMプロパティにバインドします（これは、最初のポイントでも明確に示されています）。 DOM Elementプロパティの名前className 、 classです。 では、なぜReactでclassという名前になるのでしょうか。

素晴らしい！ バンドルサイズの縮小の目標はありますか？

👏

他のすべてはどうですか？ まだclipPath、htmlFor、tabIndexなどを実行しているのは奇妙に思えます。

私は議論の余地がありますが、これらの変更は価値がないと主張します（ forを除いて）。

イベントシステムの書き直しが一番面白いところだと思います。 バンドルサイズを縮小し、コミュニティの貢献を容易にする重要な機会があります。

やってみましょう！

同時にJSX2.0のリリースにも取り組む価値があるのではないでしょうか。 とにかく、人々はいくつかのことを再学習する必要があります。 たぶん、ある期間に2回いくつかのことを学ぶよりも、一度にたくさんのことを再学習しなければならない方が良いでしょうか？ 私がこれを読んだときに起こったただの考え。

classNameの変更を除いて、これらすべての点が気に入っています。 他のポイントが追求している目標（DOM APIとの整合性）とはまったく矛盾しているようです。 Reactは、HTML属性ではなく、DOMプロパティにバインドします（これは、最初のポイントでも明確に示されています）。

それでも、未知のキーと値のペアを渡すと、React 16以降、属性として扱われます。したがって、すでに一貫性がありません。 また、私のコメントは、Reactがvalue属性を設定することを期待しているユーザーが間違っていることについてでした。 React APIがそのAPIで属性名またはプロパティ名を使用するかどうかは、完全に直交しています。

私はこの議論のあなたの側を何年も擁護してきましたが、今ではこれはそれだけの価値のない摩擦だと思います。 あなたはそれから何も得られません。 classを使用させるだけでは、破壊と移行コストが機能しないことを除いて、悪影響はありません。 Reactを学ぶと、誰もがそれについて不平を言います。 この場合、人々が期待することをすることは、衒学者であるよりも重要だと思います。 とにかく他のDOMを変更しているので、これをまとめてまとめましょう。

ReactFireが速く燃えている限り....👍

これらの変更はすべて素晴らしいです。 私はこれとreact-testing-libraryへの影響にとても興奮しています。 特に、イベントはリアクションルートにバインドされ（または、現代の環境では不要になったため、イベントの委任を完全に削除することもできますか？）、合成イベントを削除/書き換える可能性があり、 onChange -> onInputは、 react-testing-libraryの実装とツールの使用経験を大幅に改善します。

実装中ですので、フィードバックをお寄せください。

現代の環境ではもはや必要ないかもしれないので、イベントの委任を完全に削除することさえあるかもしれません

これを検討しましたが、これは単純化しすぎかもしれないと思います。 イベントの委任により、最初のレンダリングですべてのノードに多数のリスナーを設定する必要がなくなります。 そして、更新時にそれらを交換します。 これらの側面は無視されるべきではありません。 ただし、そこで行われるベンチマークはもっとあると思われます。

@tannerlinsley ({ class: className }) => <div class={className} />残念ながら、これによりjsx 2.0オブジェクトの短縮表記（ <div class /> ）が強制終了されますが、それでも...

classが最終的に文字列の横にあるオブジェクトと配列を取得できれば、とても素晴らしいでしょう。

バンドルサイズの縮小の目標はありますか？

ReactDOMの3分の1をドロップするといいでしょう。 わかります。 早く言うのは難しいですが、頑張ります。

うわー、これは、人々がReactの短所について私に尋ねたときに私が言及するほとんどすべての設計上の決定の列挙です。

これが進む方向が大好きです。

classNameを使用し、Reactの複数のバージョンをサポートしたいライブラリのアップグレードパスはどうなりますか？

@gaearon大したことではないかもしれませんが、今日は「小道具はHTML属性ではなくDOMプロパティです」と言って、「classNameを除いて、HTML名です」と言うのはいいことです。 また、Reactと一致するように、属性を10分間いじらずにSVGをコピーして貼り付けることができるようにしたいと思います。

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）。

これで、reactDOM定義を拡張せずに、reactはハンドラーをカスタム要素に委任できなくなりました。 https://github.com/facebook/react/issues/9242

これは、Reactが<x-component onMyEvent={ev => {...}} />のようなカスタム要素にカスタムハンドラーを設定できないことを意味します

@gaearon
これについて何か計画はありますか？

これらすべての変更は優れていますが、それらすべての最大のメタ変更は、私の意見ではサイズの縮小です。 Reactには平均的なDXがありますが、平均的なネットワーク、特にモバイルでのダウンロードと解析が問題になるほど太っています。

私たちはそれをすべて持つことができました！

イベントの委任を書き直すと、＃1254を修正するための扉が開かれます。 一部のイベントは、それらが接続されているノードのパフォーマンスを低下させます（Reactの場合はアプリ全体を意味します）。

また、長い目で見れば、合成データセットの小道具を用意することを検討しましたか？ 許可されたHTMLプロップを入力できない（データ-*のため）と、プロップをDOMノードに転送するときに大量のバグが発生します。 現在型付けされているReactコンポーネントは、小道具の正確な型とデータ属性の許可のどちらかを選択する必要があります。

私は興奮しています

@ryanflorence少しオフトップですが、HTMLをマップするための非常に多くの些細な変更でReactへの移行を容易にするために、誰も（私が知る限り）html / css /svg->jsxトランスフォーマーを作成するアイデアを持っていなかったのはちょっと悲しいです小道具を反応させるための属性。 非常に多くの工数が、主に検索と置換を実行するために浪費されています:(

同じ号（およびコメント）で次のことを見るのは非常に奇妙です：

私たちの目標は、ReactをDOMの動作とより適切に整合させることです
className→class
まだclipPath、htmlFor、tabIndexなどを実行しているのは奇妙に思えます。

これらすべてがDOMAPIの直接の対応物である場合

そして、この議論は召集を通過しません：

私はこの議論のあなたの側を何年も擁護してきましたが、今ではこれはそれだけの価値のない摩擦だと思います。 あなたはそれから何も得られません。 クラスを使用させるだけでは、それ以外の悪影響はありません。

Reactは常にJSの上にある非常に薄いレイヤーでした。 したがって、JSXの山かっこ以外のすべては、JSであり、DOMに直接関連するもの（ className 、 clipPath 、 htmlFor 、 tabIndexなど）のDOMAPIに直接対応するものがありました。

classを導入するという決定により、Reactは薄層ではなくなり（ classはJSで予約語になります）、DOMAPIとの互換性を高めるという宣言された目標から脱却します。

className -> classを移行することで、DOMと矛盾し、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 / react / issues / 9230

これは問題ではないかもしれませんが、ReactFireとReactFiberの類似性は、英語を母国語としない人にとっては混乱を招くでしょうか？ ここニューヨークでニューアークペンシルベニア駅とニューヨークペンシルベニア駅が同じ電車の路線にあることは、観光客にとって特に残酷な冗談だと私はよく思いました。

それが本当に懸念される場合は、それをReact Flameと呼んでも、火を維持することができます🔥絵文字。

イベントの委任を書き直すと、＃1254を修正するための扉が開かれます。 一部のイベントは、それらが接続されているノードのパフォーマンスを低下させます（Reactの場合はアプリ全体を意味します）。

＃1254を何らかの形で修正することは、間違いなく私が見たいものです。

また、長い目で見れば、合成データセットの小道具を用意することを検討しましたか？

より大きな表面があるので、私は今このようなことにコミットしたくありません。 DOMのより豊富なインターフェース（ ariaSet 、 dataSet 、 classList ）は理にかなっていますが、React DOMにどれだけ投資したいかは明確ではありませんが、より高いレベルのライブラリはより豊富なDOMAPIを提供します。 これらの変更はより見栄えがしますが、表面積が大きいので、私はそれらを控えます。

ReactBlazing🔥

@ryanflorence少しオフトップですが、HTMLをマップするための非常に多くの些細な変更でReactへの移行を容易にするために、誰も（私が知る限り）html / css /svg->jsxトランスフォーマーを作成するアイデアを持っていなかったのはちょっと悲しいです小道具を反応させるための属性。 非常に多くの工数が、主に検索と置換を実行するために浪費されています:(

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

新しい変更にとても興奮しているので、Facebookの人間はこの移行で歴史を作っています。 50kのコンポーネントがReactFireに移行されますか？
テストスイートは非常にタイトである必要があります<3

ReactFireとReactFiberの類似性は、英語を母国語としない人にとっては混乱を招くでしょうか？

多分難聴者（または単語の識別に影響を与える他の条件を持つ人々）のためにも

@gaearonを共有してくれてありがとう、それは蓄積です！

私は、JSX 2.0リリースで、BabelとTypescriptを使用してコードをコンパイルするときに発生する空白と新しい行の問題を解決することを望んでいます。

さまざまな問題が開かれ、私は貢献しようとしましたが、ReactチームがJSXの周りのすべてをレビューする必要があるために言われました。

この問題はとにかくdomに関連しているため、jsxをjsに変換する方法では、w3cの記述が許可されません。

これは問題ですhttps://github.com/facebook/jsx/issues/19

私のコメントは最後にあります。

classNameは大丈夫だと思います。 それが何であるかとしましょう。 けがに侮辱を加えないでください。

誰かがこれが既存のハンドラーにどのように影響するかを明確にできますか？

value属性への入力値の反映を停止します

Reactは、ハンドラーで正確なevent.target.value更新を使用して入力を制御しますか、それとも参照とDOMノードからの値の読み取りにのみ影響しますか？

@nickmccurdyブラウザのdevtoolsに表示される内容に影響します

@tomdaleReactEmber🔥

良い！ React17での変更の完全なリストが表示されるのを待っています。
ReactJSの新時代になると思います。 🔥⚛️

@tomdaleうーん：毛糸、繊維、布; 多分別の衣類関連の用語を使用することができますか？ 😆

それでも、未知のキーと値のペアを渡すと、React 16以降、属性として扱われます。したがって、すでに一貫性がありません。

@gaearonは、ReactがCustomElements Everywhere相互運用テストでスコアが悪い唯一のライブラリである理由でもあります： https ：//custom-elements-everywhere.com/

いいえ、それは理由ではありません（カスタム要素と通常の要素は完全に別個のコードパスです）。 その理由は、私たちはすでに古い振る舞いをしていて、新しい振る舞いがしっかりしていない限り、後方互換性を破りたくなかったからです。 この傘の一部として、より優れたカスタム要素の相互運用に取り組むことは理にかなっていると思います。

ReactFireとReactFiberの類似性は、英語を母国語としない人にとっては混乱を招くでしょうか？

どちらも内部コードネームであり、プロジェクトが完了すると、実際には何の意味もありません。 React Fireは、React DOMを改善するための単なる取り組みであり、本番環境に対応できるようになるまでには、ReactDOMになります。

Reactは、ハンドラーで正確なevent.target.valueを更新して入力を制御しますか、それとも参照とDOMノードからの値の読み取りにのみ影響しますか？

はい、 event.target.valueはプロパティであるためです。 属性の更新を停止することについて話しています。 他の人気のあるライブラリ（AFAIK）はなく、無数の問題を引き起こします。 値をCSSセレクターに依存している場合を除いて、コードに影響を与えることはありません（とにかく悪いでしょう）。

良い！ React17での変更の完全なリストが表示されるのを待っています。

これが17までに準備できることを約束していないことに注意してください。18または19になる可能性があります。😅

Reactのような優れたライブラリが着実に開発されているのを見るのは素晴らしいことです。 🎉 classは、使いやすさを大幅に向上させます。それだけの価値があります。

@gaearon

カスタム要素と通常の要素は完全に別個のコードパスです

それ自体も修正するもののようです。 すべての要素を同じように扱わない理由はありますか？ これがHTMLとDOMの仕様の意図です。

@justinfagnani前述のように、当時私たちがそれをしなかった理由は、プロパティと属性のどちらを設定するかを判断する方法の規則がなかったためです。チェックを使用すると、それを行うリスクがありました。 Webプラットフォームがプロトタイプに新しいプロパティを追加することは不可能です。 @robdodsonが取り組んでいるRFCとPRにはすでに何らかのコンセンサスがあり、おそらくそこからそれを拾い上げることができると思います。

👍🔥🔥🔥

React Fireを使用すると、Infernoが持っている巧妙なパフォーマンスの最適化の一部を適用することもできますが、重大な変更のために適用できませんでした。 エキサイティングな時代:)

LGTM

提案されたclassName -> classの名前変更に関連：文字列の配列をとるclassesプロパティが欲しいです。 これにより、コンポーネントでの多くの文字列操作（またはクラス名の使用）の手間を省くことができます。

classesプロップの唯一の欠点は、同じ文字列を同じ順序で含む配列が純粋なコンポーネントで再レンダリングされるのに対し、同じCSSクラスの文字列は再レンダリングされないことだと思います。 正直なところ、それは小さな問題のようです。 ほとんどのReact開発者は、小道具の配列とオブジェクトのトレードオフをすでに知っていると思います。

@gaearonには下位互換性の計画がありますか？ たぶん、React Fiberと同じパスをたどり、変更に関する警告を追加し、新しい更新を失うことなく、大規模なコードベースの更新に時間をかけます。

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

classとclassNameについて。

どちらに行っても、これについて幅広い合意は得られないことを私は知っています。 人々はこれについて本当に強い意見を持っています。 お役に立てば幸いです。

コンポーネントAPIは慣用的に感じるはずです

Reactは「JavaScriptと一致する」という一般的な議論があるため、 classNameが優先されます。 この主張は微妙に誤解されていると思うので、少し焦点を当てたいと思います。

Reactでは、何よりもまず、Reactコンポーネントの使用が慣用的なJavaScriptのように感じられるようにする必要があります。 これは、架空の<Table>コンポーネントを使用する場合、その小道具はキャメルケースであると期待していることを意味します。

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

コンポーネントのパブリックAPIにrow_heightやrow-heightのようなプロップ名が表示されることは期待していません。 コンポーネントの小道具はオブジェクト（「オプションバッグ」のようなもの）であり、通常、これらのオプションは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（両方に1つの抽象化がある）を使用することから考える方法ではないかもしれません。

Reactはプロパティを設定するだけではありません

よくある誤解は、Reactは現在ほとんどのDOMプロップにcamelCase規則を使用しているため、ReactがDOMプロパティを設定していることを意味します。 これは間違っています。

実際、Reactは現在、サポートするほとんどすべての小道具に属性を使用しています。 valueのように、これが問題を引き起こしている場合があります（これについては、後で説明しました）。 それ以外の場合、これは実際には素晴らしいことです—サポートされているプロパティのリストをReactバンドルに含める必要がないためです。 内部で属性を使用することで、React16で大幅なサイズの縮小が可能になりました。

ここでの私のポイントは、 Reactが内部でプロパティまたは属性を使用するかどうかは実装の詳細であり、React DOM要素_API_がプロパティ名、属性名、または意味のある他の名前を使用する必要があるかどうかとは関係ありません。

それでも、プロパティ名だけを使用しましょう。

さて、プロパティと属性は実装の詳細です。 しかし、DOMプロパティ名は「JavaScript用」に特別に作成されているので、標準化してみませんか？ それが今日のReactAPIの設計方法ではありませんか？

まあ、完全ではありません。 以下に列挙されている小道具の1つだけが、実際のDOMオブジェクトプロパティに対応しています。

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

皮肉なことに、それに対応する同じ名前の実際のDOMプロパティ（わからない場合はtabIndex ）を持つ上記の唯一の小道具は、実際にはReactによって属性として設定されています！

したがって、この時点までに、それが明確でも一貫性もないことがわかるでしょう。 プロパティが存在しない場合（カスタム、非標準属性など）、場合によってはReactはより豊富なAPI（ data-対dataSet ）を提供できますが、現在は存在しません。

場合によっては、Reactは、カスタムReactコンポーネントの方が理にかなっているため、意図的に逸脱することを選択します（ReactのonClickとonclick DOMプロパティ）。 これは、ReactコンポーネントがonItemClickのようなより複雑なイベントハンドラーを公開することが多いためです。 <Button onclick>と書いたが、 <Table onItemClick>と書いた場合、非常に一貫性がなくなります。 また、 <Table onitemclick>はキャメルケースではありません。これはコンポーネントAPIで避けたかったものです。

上記で、Reactは「常にDOMプロパティ名を使用する」ことについてはすでに一貫していないこと、Reactは実際には内部でプロパティを使用していないこと（経験則では実際のメカニズムも説明されていないこと）、および多くの場合で説明しました。 DOMプロパティが存在しない場合は、属性名を許可することに固執する必要があります。

プロパティ名でない場合は、一貫性を保ち、属性名を使用しましょう。

では、属性名だけを使用してみませんか？ これはもっともらしいかもしれません。 しかし今、私たちは私たちが提起した最初の考慮事項にぶつかります。 Reactコンポーネントの使用は、慣用的なJavaScriptのように感じるはずです。 ただし、多くの場合、コンポーネントは少なくともいくつかの小道具を基になるDOM要素に転送します。

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

 // renders...

 <button
   tabIndex={1}
/>

カスタムButtonが一貫性のない大文字の小道具を受け入れるのは厄介です。

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

これにより、消費者は、特定の小道具が実際のDOM小道具なのか、それともコンポーネント契約の一部なのかを常に覚えておく必要があります。 その区別でさえ曖昧です—コンポーネントは最初に特定の小道具を通過させることを選択するかもしれませんが、それから実際にいくつかの追加のロジックのためにそれを使い始めるかもしれません。 「DOM小道具」と「その他の小道具」の境界はどこにありますか？

これが、 tabIndex 、 cellSpacingなどの小道具やその他のほとんどのDOM関連の小道具がキャメルケースの規則に従うことが望ましい主な理由だと思います。 それは、それらがコンポーネントAPIになってしまうことが多いためです。

Buttonなどのカスタムコンポーネントを、DOMに流入する時点で属性名に「変換」することなく、また非キャメルケースの小道具を導入することなく、簡単にラップして転送できるようにしたいと考えています。カスタムコンポーネントAPI。

これは、 data-* 、 aria-*などの小道具やカスタム属性が妥当な例外である理由も説明しています（より豊富なAPIを作成できたとしても）。 カスタムコンポーネントに渡されることはめったにありません。 通常、これらはDOMに結合されすぎているため、カスタムコンポーネントで使用できません。代わりに、より豊富なキャメルケースAPIを使用した<Modal>や<Button>などの実装の詳細になります。

ReactプロパティはすでにDOMプロパティと一致していません

「DOMプロパティ名」の規則がうまくいかなかった場合は、別のものが必要です。 それは何ですか？ 「属性名のキャメルケースバージョン」でしょうか？ ほとんどの場合、これはすでにチェックアウトしているようです。

これが過激に聞こえる場合は、すでにこれを行っていると考えてください。 srcSetと呼ばれるものをサポートしています。 ただし、そのDOMプロパティ名はsrcsetです。 autoCapitalizeがありますが、DOMプロパティはautocapitalizeと呼ばれます。 autoFocusがありますが、DOMプロパティはautofocusです。

キャメルケースのJavaScript規則と一致しない場合、すでにDOMプロパティ名から逸脱しています。 これでclassなります。

最後に： className vs class

それをclassNameにする最初の理由の一部は、ReactがDOMプロパティを設定していたためであり、 classNameはDOMプロパティの名前です。

ただし、上で説明したように、Reactは3つまたは4つの特殊なケースを除いてプロパティを使用しなくなりました。 さらに重要なことに、ReactはDOMプロパティ名を一貫して使用することすらありません。むしろ、DOM属性とプロパティ名のいずれかの内部命名の不一致に関係なく、JavaScriptから使用すると自然に見える名前を使用します。 これは、Reactがカスタムコンポーネントのプロップ名を「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の破壊を奨励することがどれほど価値があるかは明らかではありません。 小道具からコードを読み取るには、もう1行のコードを記述する必要があると思います（または、 props.classを使用して、それについて考えないでください）。

DOMに非常に近いコンポーネントを作成している場合（したがって、 classを小道具として使用するのが理にかなっている場合）、他の小道具も転送することをお勧めします。 したがって、destructuringでrest構文を使用できます。

// Valid in ES2018

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

また、変更する必要がない場合は、 classを読み取らずに、 {...rest}を転送することもできます。 したがって、破壊の制限は、より良いコンポーネント設計を促進するのに役立つ可能性があります。

なぜ両方ではない？

最後に、 classとclassNameの両方をサポートすることはできませんか？ ある意味では、私たちはすでにそうしていますが、Reactは警告とともにあなたに怒鳴ります。 これには理由があります。

警告なしに両方をサポートする場合、コミュニティはどちらを使用するかを分割します。 クラスpropを受け入れるnpmの各コンポーネントは、両方を転送することを忘れないでください。 真ん中の1つのコンポーネントでもうまく機能せず、1つの小道具しか実装しない場合、クラスは失われます。または、下部にclassとclassNameがそれぞれ「不一致」になるリスクがあります。その他、Reactがその競合を解決する方法はありません。 ですから、それは現状よりも悪いと思い、これを避けたいと思います。

概要

Reactが今日オープンソースだった場合、 class （ほとんどの人が期待するものに概念的に近く、最も一般的に使用される小道具のタイピングが少ない）を許可することの長所は、短所（それを傍受するためのタイピングが少し多い）を上回っているようです。いずれにせよ、おそらくスプレッド演算子が必要になるでしょう）。

DOMプロパティを設定しなくなったため、またDOMプロパティとの一貫性を保つように努めていないため、以前は欠点（DOMプロパティと矛盾している）と見なされていました。 代わりに、Reactコンポーネントの消費側で属性ベースのキャメルケースAPIを使用することを目指しています。これは、すでにほぼ一貫しています。 また、 class="Button"はclassName="Button"よりも明らかに便利です。 実際、DOM APIが今日設計された場合、このような割り当てでのclassの使用に関する制限が、ほぼ10年前にES5で解除されたため、おそらく.classプロパティを設定できます。

残っている唯一の大きな欠点は、移行コストです。 これを注意深く評価します。 しかし、とにかくたくさんの変更を行っている場合は、これも作成して完全に修正できる可能性があります。 私たちはこれについて軽視しているわけではなく、あなたの懸念をすべて考慮に入れています。

注：これは、camelCased属性名と一致しない他のReactプロップ名に対して行うのが理にかなっている場合があります。

@renatoagds

下位互換性の計画はありますか？ たぶん、React Fiberと同じパスをたどり、変更に関する警告を追加し、大規模なコードベースの更新に時間をかけます。

私が述べたように：

また、Facebookには、移行戦略について正直に保つために5万を超えるコンポーネントがあります。 いくつかの対象を絞った修正または自動化されたコードモッドを除いて、製品コードを書き直す余裕はありません。

そのため、いつものように、移行戦略をできるだけスムーズにするように努めます。 スムーズでなければ、自分で変更することはできません。

re：className-> class、どちらの決定でもかっこいいです。新しいユーザーのクラスを変更する場合の例外と、コード行が短いという副次的な利点を確実に理解できます。 ただし、他のキャメルケースの名前についてはまだ学ぶ必要があります。

したがって、クラスに残された唯一の不便は、これを書くことができないということです：

const { class } = props;

しかし、時間の経過とともに、この議論はそれ自体では十分に強力ではないと思います。 Reactは、>破壊、および書き込みの使用を強制しません

const class = props.class;

それほど多くの努力ではありません。

2つの（おそらく小さい）もの：

1. const class = props.class無効なJavaScriptではありませんか？ 私はそれがそうであるとは思いませんでした、そして簡単なテストで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申し訳ありませんが、私の心は空白になりました—その通りです。 編集しました。

@jamespleaseあなたは正しいです。 これは、デフォルト値としてJSONを使用する場合にも頻繁に発生するため、煩わしいです。

const { default: defaultVal } = property

イベントシステムを変更しているときに、InfernoのlinkEvent関数に似たものが表示されると非常に便利です。これにより、レンダリングごとに匿名関数を作成しなくても、機能コンポーネントの小道具を使用してイベント処理を実行できます。

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に対するもう1つの議論は検索可能性です。 JSクラスコンポーネントを使用するES6コードでCSSクラスを使用するコンポーネントを検索したい場合、誤検知がいくつあるとclassで検索できますか？ はい、 class={を検索できますが、JSでオブジェクトとして作成されたJSXの小道具を破棄するのはどうでしょうか。 （私は小道具の破壊を多用することに反対していますが、それらはまだ使用されています）もちろん、コードエディターにはより優れたコンテキストアウェアASTベースの検索ツールが必要ですが、今のところテキストと正規表現しかありません。 もちろん、型システムはオブジェクトの通過を追跡するのに役立つかもしれませんが、大勢の人はそれらを採用していません。

予約語を使用することについての何かは、それが今問題を引き起こさないとしても、私にはぴったりではありません; rest.class （たとえば）がx年以内に言語にとって重要ではなくなることを確かに言うことができますか？

@GeordiePそれが今日うまくいくなら、それは明日壊れることはできません。 これがJavaScriptがどのように進化しているかの核となる原則であり、JavaScriptの多くの特異性の理由です。

@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をうまく処理できるかどうかはわかりません。 ハッカソンプロジェクトは、React（https://github.com/reactjs/react-magic）を使用してプレーンなHTMLサイトを「ajaxify」するスクリプトを作成することでした。その一部として、Reactコンポーネントを作成する方法を構築する必要がありました。 HTMLのチャンクから、別のスタンドアロンページとしてHTMLからJSXへの部分をリリースしました。

IE11のサポートには引き続き関心がありますが、既存のブラウザーの違いの一部をスムーズにしようとしない可能性があります。これは、多くの最新のUIライブラリで採用されているスタンスです。

@gaearon-ブラウザの違いをスムーズに処理しない最新のUIライブラリの例をいくつか挙げてください。 私にとって、それがライブラリを使用する主な理由の1つです。

陰謀説：このclassName / classニュース全体は、誰もがすぐに注意を払い、議論するであろう1つの明るい物議を醸すものです。 それは、リワークプロジェクト全体に注目を集めるか、影の中で起こっているより大きな何かから気をそらすか、次の逸話のように、残りが受け入れられる間に後で撤回できるものを1つ与えるかのいずれかです。

小さな緑の犬を描いている隅に、風景のスケッチを作成している偉大な演劇芸術家タイシュラー。 そして、入会委員会の一人が「私はすべてが好きですが、この犬はどこにいますか？」と尋ねたとき、後悔のため息をついた芸術家は彼女を塗りました。

この変更の背後にある本当の理由は明らかではありませんが、この新しいアップグレードプロジェクトの人気はすでに急上昇しており、コミュニティはReactをめぐって話題になっています。

パッシブイベントリスナーのサポートが、モバイルの重要な機能であるReactFireの範囲内にあると便利です。

6436

これにご尽力いただきありがとうございますが、 className -> classを再検討してください。

私たちはかつてReactの初心者でしたが、 classNameは、Reactを学び愛することを妨げませんでした。

jsxでvueを使用しているとき、彼らはすでにclassName classを持っていたのを覚えています。Reactは仮想DOMのパイオニアであるため、classNameがclassに変更されるかどうかは同意しません。 、およびDOM自体を表します。

ドキュメントではなくReactルートにイベントを添付する

@gaearonこれは、テスト環境で、実際のブラウザーイベントをディスパッチし、それらに関連付けられたハンドラーを呼び出すために、ドキュメントに要素を追加する必要がないことを意味しますか？ これを行わなければならないことは非常に直感に反し、Reactの内部に不慣れな多くの開発者が混乱し、テストの作成に多くの時間を浪費し、イベントシミュレーションや不十分なテスト慣行に陥る原因となっていると確信しています。

それは私を別のメモに連れて行きます、私たちはreact-dom/test-utilsについて何かをすることができますか？ 私は、 Simulateに関連するすべての問題を考慮して、削除の可能性に特に関心があります。もちろん、 react-dom自体に必要な変更を加えて、本当に必要ないようにします。もう。 それは範囲内でしょうか？

/ cc @kentcdodds

ReactFireが取っている方向性と全体像が大好きです。 これまでのところ、それらは取り組むべき大きな変化のように見えます。

発表されたほとんどの変更が大好きですが、私はclassNameの変更に懐疑的です。

Reactは、この特定の変数名を破壊したり使用したりすることを強制するものではなく、（...コードスニペット...）のようなものを書くことはそれほど手間がかかりません。

書くのはそれほど努力ではありませんが、私の現在の経験では、他の開発者（特に他の言語の開発者）に説明するのは_かなり_難しいと思います。 一方、私たちが会社でReactを使用していたすべての年で、 classNameによって混乱した開発者は1人か2人だけで、数分以内にクラス名を設定するためのReactsAPIとしてこれを受け入れたと思います。

（私が破壊するのが大好きな私の個人的な意見では、名前の変更の構文は、非常によく似ており、デフォルト値のようなものと組み合わせることができるインポートでの名前の変更とは異なるため、初心者にとってはそれ自体が奇妙に感じることがあります。 、しかし、それは私たちが現在私たちの会社で書いている他のすべてのコードの_大きな_例外です。他の人からの経験はもちろん異なるかもしれませんが、それは問題に関する私の見解です🙃。）

すごい

また、 classNameの変更についても懐疑的です。 これは、物事のスキームにおける最も小さな変更の1つですが、ここでのコメントの議論の大部分を引き付けています。

発表されている他の多くの良いものがあるとき、変化にそれだけの政治的資本を費やすことは本当に価値がありますか？

私の立場からすると、正当化の一部が「...のようなものを書くことは、それほど多くの努力ではない」という決定を下している場合、その決定には_大規模な_上向きが必要です。 className -> classの変更は、発表された他のすべてのものと比較しただけではありません。

これは🔥ReactFireの大きな進歩になります

class v / s classNameについては、JSX≠Reactであることを思い出してください。

JSXはHTMLのように見えるように設計された_DSL_であるため、可能な限りHTMLに近づけることが最善です。 確かに、DOM APIではclassNameと呼ばれていますが、ほとんどの場合、DOMAPIを直接処理したくないためにJSXを使用しています。

ReactのAPIがDOMAPIと厳密に一致する方が理にかなっている場合は、トランスパイルでマッピングを実行しても問題がないことを願っています。
<img src="avatar.png" class="profile" /> → React.createElement("img", { src: "avatar.png", className: "profile" }) 。

JSX構文をHTMLのクリーンなスーパーセットにすることは非常に価値があります。

@mhenr18が言ったことに追加します。

物事の現状：

• Reactに一貫性がない
• APIはキャメルケースです

提案された状態：

• Reactに一貫性がない
• APIはキャメルケースです
• className -> class

認識される利点：

Reactが今日オープンソースだった場合、クラスを許可することの長所（ほとんどの人が期待するものに概念的に近く、最も一般的に使用される小道具の入力が少ない）が欠点（それを傍受するための入力が少し多い-その場合はとにかくスプレッド演算子が必要なだけかもしれません）。

実際の欠点：

• classNameに依存するエコシステム全体が機能しなくなります（膨大なアップグレード作業）
• 膨大な数の本、チュートリアル、例、コード、投稿、記事がこれまでになくわずかに無効になります
• 残っている唯一の有効なJSは、追加の入力です： const {class: cls} = props 。 プレーンJSで考えられる他のすべてのユースケースは無効になります
• React APIは一貫性がなく、さらなる仮定を破ります（なぜhtmlForがforはないのかなど）

私がプロダクトマネージャーだった場合、変更に対する私の即時の反応は次のようになります。

@gaearonすでに検討されているかもしれませんが、PRに「ReactFire」または同様のキーワードのタグを付けてください。

通常、問題には正しくタグが付けられますが、PRにタグが付いていない場合もあります。 これは潜在的な貢献者を助けます。
これは、ファイバー開発全体でReactFiberおよびReactReconciler関連のコミットを探してgitの履歴を読み込もうとしたときの私の経験から来ています。 これは、何が起こっているのかを理解し、何らかの形で貢献できるかどうかを確認しようとしている私たちの助けになります。

また、 classNameの名前をclassに変更すると、新しい開発者にとって非常に大きな移行作業と問題が発生すると思います。
className属性は非常に目立ち、頻繁に使用されるため、reactに依存するすべてのライブラリが文字通り壊れます。
そして、これは十分ではありません、ほとんどのチュートリアルは壊れます。 記事からの新しいデバイスのコピーと貼り付けは、「なぜそれが機能しないのか、 classNameは有効な小道具ではないと言っているのか」と疑問に思うでしょう。
ですから、先輩は助けなければならず、私たちは何も得ていません。なぜなら、それがあなたが期待するように機能しない理由をまだ説明しなければならないからです。
実際には、コンポーネントでクラスを定義するためにclassNameを使用する必要があることを説明するのに、1分もかからず、簡単に理解できます。 すべての開発者にclassNameからclassに変更した理由を説明すると、はるかに時間がかかり、フラストレーションが高まります。

一言で必要なすべての努力。
反応の振る舞いは何も変わりません。
それはreact-domの開発を後押ししません。
反応で1週間以上働く開発者の生産性は向上しません。
それはただすべてを壊します。

考えてみてください、本当に価値がありますか？

私は何年もの間babel-plugin-react-html-attrsを使用していて、それは私に役立っていますclassNameの名前をclassに変更するのは良い考えではないと思います。 私が言及したようなプラグインによってよりよく達成されます。

「 class v className 」/「 for v htmlFor 」の状況全体を処理するBabelプラグインはありませんでしたか？

すでに行われた命名決定との下位互換性を維持しながら、html属性をそのままサポートできることを願っています。

変換を行うためのbabelプラグインがすでに存在するという事実は、おそらくコアJSXトランスパイラー自体でそれをサポートできるはずであることの証拠です。 しかし、それを公式の仕様にすることで、誰にとっても非常に簡単で信頼できるものになります。

私はReactの内部を知らないので、本当の実現可能性についてはあまり言えません。 使いやすさの観点から、私がどのように「あるべきか」を表現するだけです。

classNameとclassを再検討してください。 上で述べたように、ゲインはほとんど存在しませんが、実際のデメリットがあります。

1つは、Haxeをreactアプリケーションを作成するための言語として使用している場合、これは重大な変更であるだけでなく、単に_any_reactアプリケーションを作成できなくなるだけです。

classはほとんどのプログラミング言語で予約されたキーワードであり、このプロップを操作できなくなったため、reactアプリケーションはほぼ不可能になりました（クラスを操作せずに実際のアプリケーションを作成することをお勧めします）。 悲しいことに、 htmlForとforについても同じことが言えます（これは本当に醜いですが、存在することに感謝しています）。

ちなみに、検索性...「Reactクラス」をグーグルで検索すると、Reactクラスコンポーネント、Reactクラス属性の混合シグナルが表示されます。 「ReactclassName」をグーグルで検索すると、古いドキュメントが表示されます（上記の人々は、コードのアップグレードに加えて、この変更によって大量のアップグレード作業が行われています）。

このプロジェクトの目標は、コミュニティのためにより多くの仕事を生み出し、インターネットのためにより多くのノイズと混合信号を生成することですか？ 私はそうしないことを望みます。

はい、WebとJavaScriptのエコシステムは、過去の愚かな過ちとのバックコンパットを維持するのに苦労していますが、このバックコンパットへの取り組みは、大きな断片化なしにそのような規模に成長することを可能にしました。

変化なくして進歩はないことを理解しており、私は初期のFBのモットーである、物事を壊して速く動かすことを採用しました（事前にそれらを再組み立てする方法も計画しています）。

この変更が本当に必要になるほど永続的である場合は、変更の本当の理由を教えてください。 それは「学ぶのが難しい」ことではありえません。強力なReactCoreチームには浅すぎるように聞こえます。 あなたは間違いなく何かを心に留めておくべきです。

@sompylasar私は通常className=またはclassName：を検索しますが、これらは両方ともクラスでも機能するようです。

また、githubで直接それを行うことを頑張ってください= /

ここですべてのコメントを読みました。 変更は問題ありませんが、 classについてはよくわかりません。 主な理由は、JSX2.0のプランでは機能しないためです。 ショートカット表記について（現在オブジェクトにあるように）。
他のすべては非常に素晴らしい改善のようです。
最終決定を待っています:)皆さんの素晴らしい努力に感謝します！

あなたのコメントの1つで、「今日うまくいくなら、明日うまくいくはずだ」とおっしゃいました。 私の質問の前にこれを覚えておいてください;）。

Reactのすべてのバージョンを15.4に戻すことを目的としたRMWChttps : //jamesmfriedman.github.io/rmwc/というUIライブラリを維持しています。 統一されたAPIサーフェスを維持することはできましたが、classNameをclassに、onChangeをonInputに変更し、イベントシステムをオーバーホールすると、これを続行することはほぼ不可能になります。

このようなものの一部を内部で変換できる「互換性」レイヤーの可能性はありますか？ だから私はreactfireがどんなバージョンでも書くことができますが、より低いランタイムで実行し続けます。

そうでなければ、私の奇妙なコードはもっと奇妙になると思います。 👀

classNameが本当にclassに変更する必要がある場合は、 htmlForもforに変更してください。
classとforは、 propsを破棄すると元々無効だったためです。

Reactに多くの属性名を正規化して一貫性のあるAPIを作成する独自のAPIがある場合は、確かにclassNameがそれに最適です。 キャメルケースのイディオムに加えて、1つの追加の慣用的な学習に加えて、DOMプロパティ名（他のJSX属性の一部と同様）にマップされるという事実は、使用するたびに特別なケースとして構造化する必要がある場合と比較して、確かに問題ありません。それをオンにした小道具オブジェクト。

今まで、現状に反対する声（「どうして授業ができないの？！」）を聞いて、喜んで使ってくれた人はみんな静かに過ごしていたような気がします。 人々は肯定的なレビューよりも否定的なレビューを与える可能性がはるかに高いという古い格言と一致しています。 個人的には、他の多くのものの上にある小さな学習曲線は、この小道具が現れるたびに特別なケーシングよりもはるかに優れていると思います。

私はそれの周りにもう少し民主主義を見たいと思います-この非常に具体的な変更は委員会によって行うことができると思います（それは本質的にあなたにこの変更を検討させた疑似委員会でした）-そして私は参加できてうれしいです負ける側。 ただそれが毎日最も少ない人々に影響を与えるように。

Ps他のすべては素晴らしいところで、特にイベントのもの👌🏻

新しい更新を待っています

@gaearonあなた自身の例を検討する価値はありますか？

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

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

バグが含まれていて、期待どおりに機能しませんか？ 「それを分解しないでください」ほど簡単ではないかもしれません。

クラスがclassNameであることをそれほど心配していなかったのは私だけですか？ どんな問題が反応したかを私に尋ねるとしたら、それは私の頭に浮かぶことさえありません。

それでも、アップデートは景品であり、私は景品が大好きです。

クラスがclassNameであることをそれほど心配していなかったのは私だけですか？

授業は全然気になりません。 IE11の微妙なバグはもっと面白くなります（それでも私はこれらの変更で大丈夫です）

パッシブイベントリスナーのサポートが、モバイルの重要な機能であるReactFireの範囲内にあると便利です。 ＃6436

同意します。 それは間違いなくこの仕事の範囲内です。

ねえ@gaearon-まず第一に感謝します。

人々がどのように反応しているか、どのAPIが使用されているか、何が混乱しているのかについての情報を収集するために調査を行うことを検討しましたか？

Reactは私のお気に入りのフロントエンド開発スタックですが、Reactを学習して最初に使用するときは、いくつかのフットガンがあります。 私が教えた人々が個人的に混乱していると感じたものを単にレイアウトしたくはありません。

個人的に関わったプロジェクト（Node、Bluebirdなど）で役立つことがわかりました。

私が個人的にコアで見たいものに関しては、よりシンプルで非グローバルな依存性注入のサポート、より優れた、より一貫性のあるイベント処理（すでに説明しています）が欲しいです。

人々がどのように反応しているか、どのAPIが使用されているか、何が混乱しているのかについての情報を収集するために調査を行うことを検討しましたか？

私はreact-nativeにはcanny.ioがあると思います

Reactのすべてのバージョンを15.4に戻すことを目的としたRMWChttps : //jamesmfriedman.github.io/rmwc/というUIライブラリを維持しています。 統一されたAPIサーフェスを維持することはできましたが、classNameをclassに、onChangeをonInputに変更し、イベントシステムをオーバーホールすると、これを続行することはほぼ不可能になります。

このようなものの一部を内部で変換できる「互換性」レイヤーの可能性はありますか？ だから私はreactfireがどんなバージョンでも書くことができますが、より低いランタイムで実行し続けます。

私はあなたの懸念に共感します（私は図書館の公平なシェアも書きました）。 ただし、何かを変更することには非常に多くのトレードオフがあるため、複数のバージョンをサポートするのではなく、アップグレードを支援することに力を注ぐという側面に誤りを犯す傾向があります。 これをまったく行わないという意味ではありませんが（16.3でライフサイクルの変更のためにライブラリ作成者向けにポリフィルをリリースしました）、このユースケースに最適化されていません。

私の提案は、何か互換性がない場合に新しいメジャーをカットするときに新しいメジャーをカットすることです。 必要に応じて、ライブラリの古いメジャーバージョンを使い続けることができます。 特に開発を続ける場合は、維持するのがより手間がかかることは知っていますが、単一のハッキーなコードベースが、2つの分岐しているが一貫性のあるコードベースよりも優れているかどうかは疑問です。

@jamesmfriedman新しいAPIに（自動的に）更新してから（ビルドプロセスの一部として）古いAPIに（再びcodemodを使用して）変換することが可能である必要があります（それほど複雑ではありません）。 次に、両方のバンドルを出荷し、Reactバージョンに基づいて動的に要求します。

これはいくつかの作業ですが、（たとえば、webpackプラグインまたはnpmインストールスクリプトとして）一度実行でき、難しいことではありません。 一度リリースして、すべてのライブラリで使用するようなものだと思います。

特にライブラリ用のコンパイル時互換性レイヤーのように。

forのhtmlForの削除をサポートします。

classNameとclassの両方をサポートするブリッジリリースは良い考えだと思いますか？ これにより、開発者は古いサードパーティのReactコードを使用できるようになりますが、現在のファーストパーティのコードは将来的に使用できるようになります。 サードパーティが更新すると、ブリッジパッケージを削除するのと同じくらい簡単に、完全に最適化されたReactDOMを使用できます。

React APIは一貫性がなく、さらなる仮定を破ります（htmlForがない理由など）

forも変更する必要があると言ったときに、最後の文を見逃したと思います。 そうすれば、1つまたは2つのまれなSVG属性を除いて、「キャメルケースの属性名」と完全に一致すると思います。 これも変更できます。

「classvclassName」/「forvhtmlFor」の状況全体を処理するBabelプラグインはありませんでしたか？

私はこれについてかなりの数の言及を見ているので、明確にしたいと思います。 Babelプラグインは、次のような場合には機能しないため、この変換を行うのに最適な場所ではありません。

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

また、 classを渡しても、コンポーネントの小道具でclassNameを取得することは意味がありません。 または、プラグインがプラットフォーム要素のみを対象としている場合、 buttonをButtonに置き換えると、 classプロップのコンパイル先が変わるのは奇妙なことです。

これにBabelプラグインを使用すると、作成しているコードのセマンティクスがわかりにくくなり、混乱が生じます。 私の見解では、 classNameまたはclassのみを許可するよりも悪い解決策です。

おもしろい事実：これは、非常に古いバージョンのJSXコンパイラがどのように機能したかです。 この動作は、混乱を招くため削除されました。

素晴らしい変更。 。 。

すばらしい！ このようなエキサイティングなアップデートを提供するために尽力してくれたすべての貢献者に感謝します。
className > classがこんなに大きなスキャンダルだとは思いもしませんでした。 個人的には慣れてきました。

バンドルサイズの縮小とイベントシステムのアップグレードは非常に有望です。 超興奮！

イベントシステムのポリフィルを個別のパッケージとして分離することを本当に楽しみにしています。
しかし、className> classが過激すぎるかどうかにかかわらず、Reactの影響は広すぎます。
これは多くのシステムの予期せぬことにつながるのでしょうか？

ReactDOMの3分の1をドロップするといいでしょう。

Webアプリ開発でReactを使用すると素晴らしいでしょう。

keyやrefのような特定の小道具に名前空間を反応させるのもいいでしょう。 例えば

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

これはここで議論されています-https://github.com/facebook/jsx/issues/66

@elado将来的にやりたいことかもしれませんが、DOM固有ではないAPIに影響を与えるため、範囲外だと思います。

エキサイティングですが、特にバンドルサイズの縮小は常に歓迎されています。 私の心配は、Facebookの人々が、APIの変更がエコシステムとコミュニティに引き起こす可能性のある慣性、苦痛、断片化を過小評価していることです。

FBには心配すべきコンポーネントがたくさんあるのは事実ですが、彼らが得た利点は、ほとんどのコンポーネントを内部で構築した可能性が高いため、外部のオープンソースの反応ライブラリへの依存が最小限であることです。 多くのオープンソースライブラリを使用している他の人々にとって、Proptypesを多くのライブラリから取得するのを待ってフラストレーションを感じるのは本当に大変な労力を要しました（そして私は大規模なreactコードベースをアップグレードした実際の経験から話します）。 限られたリソースで安定したビジネスを構築したい人には、速く動いて物事を壊すことは当てはまらないかもしれません。

私は本当に反応を楽しんでいます。APIはシンプルで、個人的にはその構文を学び、調整するのに時間がかかりませんでした。 したがって、私はメンテナに、エコシステム全体の破壊的な変更の長所/短所を注意深く評価し、変更がエコシステム全体の書き直しを強制する必要があるかどうかを実際的に考えるように強く求めます。

それ以外は、Reactの構築、保守、アップグレードの努力と、その背後にいるエンジニアの情熱に本当に感謝しています:)

これらの将来の{...更新}は🔥です

className -> class ：クラス属性がJSX/オブジェクト宣言の外部で定義されている場合はまれな状況ではないと思います。 このような状況では、同じものに異なる名前を使用する必要があり、不整合が生じ、コードの複雑さが増し、認知的負荷が増大します。
提案された変更は、コードベースから属性/プロパティ名の不一致を削除しません。構文の制限のため、またはネイティブDOMを使用している場合は、どこかに存在します。 この命名の問題に対する回避策を「標準化」した（そしてこの時点で十分に確立した）ことは良いことです。
現在、 classNameはどこでも一貫して使用でき、ネイティブDOMを使用している場合でも、常に同じものを参照します。 実際、reactは文字通り唯一の場所であり、クラス属性を参照するためにclassを使用する必要があります。
classNameは最初から非常に不必要で少し混乱しているように見えましたが、後でかなり実用的で、比較的慣れやすいことがわかりました。

また、 dangerouslySetInnerHTMLの余分なオブジェクト{ __html }は本当に不要に見えるので削除しますが、移行に関連する問題（およびおそらくこの問題とはまったく関係がない）の価値はないかもしれません。

他の変更は感情をはるかに少なくしますが、それらははるかに興味深く重要なので、fbチームの努力に感謝します。

重大な変更が多いほど、実際のユーザーアプリケーションのアップグレードに時間がかかります。 個人的には、最新の最高のReact（これは私を悲しませます）からかなり遅れています。以前のバージョンのReactは壊れたものであり、アップグレードに依存するライブラリが必要であり、遅延が発生します。

理想的には、次のようなシナリオになりたいと思います。

• ダウンストリームReactライブラリは新しいバージョンでコードを書き直し、私のユースケースにバグを導入します
• Reactはクールな新機能/バンドル削減を追加します
• 古いライブラリバージョンは新しいReactで引き続き使用できます
• はい、Reactの起動直後に新機能を使用して、ライブラリがバグを修正するのを待つだけです。

実際には、次のようなものです。

• ライブラリがコードを書き直し、バグを導入
• Reactは新しい重大な変更をリリースします
• 古いライブラリは機能しなくなりました
• 新しいライブラリは最終的に更新されます
• バグはまだ存在する可能性があります
• 私は（ケン・ウィーラーを引用すると）「新しい辛さ」ではなく、時代遅れのReactに長い間立ち往生しています。
• 悲しいな ：（

「出荷コードの観点」から見ると、すべての主要な重大なアップグレードは、すべての依存関係を更新し、すべてを再テストし、新しいバグを探して回避策があるかどうかを確認することを含む、厄介な技術的負債の巨大な部分になります。 重大な脆弱性がない限り、または何かを行うことが本当に非現実的でない限り（そしてその基準が高い場合）、優先順位が低くなります。

残念ながら、それは0.xパラダイムであり、コアWebライブラリになろうとしているにもかかわらず、Reactはバージョン番号をかき回しているため、静止するために多くの時間を費やしています。

基本的に私が言っているのは、将来の大きな変更が壊れないようにするAPIを計画してみてください。

（また、IE11のことは、EOLではないブラウザーを廃止しているため悲しいことです-前回のリリースは52日前です。Reactチームは、これがFacebookチームとすべての外部および内部ライブラリチームに作業をプッシュして軽減することを発見すると思います代わりは）。

@urugator

本当に不要なように見えるので、dangerlySetInnerHTMLの余分なオブジェクト{__html}も削除します。

これは意図的に明示的に設計されており、誤って使用することは困難です。 削除すると、サニタイズされていないデータが誤ってdangerlySetInnerHTMLに渡される可能性があります。

@philipwhiuk

基本的に私が言っているのは、将来の大きな変更が壊れないようにするAPIを計画してみてください。

技術を向上させるためには重大な変更が必要であり、Reactは、頻繁でない変更のバッチに対して責任を持ってそれを行います。 componentWillReceievePropsを削除するなどの変更を壊さなければ、React Suspenseのような優れたものはありません。また、コミュニティ内のソフトウェアは、古いAPIが永久に残っていると維持するのがより困難になります。 一度に1つのメジャーリリースをアップグレードする場合は、問題ないはずです。

また、52日前の最後のリリースであるEOLではないブラウザを非推奨にしているため、IE11のことは悲しいことです。

IE 11を廃止する人は誰もいません。Reactの現在のバージョンでは、実際にはIE 11の一部の機能にポリフィルが必要なので、提案された変更はIE11の開発にほぼ同じ影響を与える可能性があります。 https://reactjs.org/docs/javascript-environment-requirements.html

本当に不要なように見えるので、dangerlySetInnerHTMLの余分なオブジェクト{__html}も削除します。

@urugator -Facebookの内部では、 __htmlの最も一般的な使用法は、サーバーでレンダリングされたHTMLをReactコンポーネントツリーに挿入することです。 そのユースケースでは、サーバー側で__htmlオブジェクトを作成し、クライアント側でそれを実行しないようにlintルールを設定します。 サーバー側には、 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を使用していたことを指摘したいと思います。多くの場合、大規模なアプリケーションで使用されています。 したがって、これは、オープンソースユーザーに影響を与える種類の問題に共感するのに役立つと思います。 私はReactを2年間使用しており、たとえば親/所有者のコンテキストスイッチによって引き起こされた断片化をよく覚えています。 重要なのは、優れた移行戦略を立てることでした。これは、上記のすべての変更にも当てはまります。

FBには心配すべきコンポーネントがたくさんあるのは事実ですが、彼らが得た利点は、ほとんどのコンポーネントを内部で構築した可能性が高いため、外部のオープンソースの反応ライブラリへの依存が最小限であることです。

これは歴史的に、開発の製品側にも当てはまります。 ただし、Yarnが作成され、Webリポジトリと統合されて以来、内部ツールページで使用されるサードパーティコンポーネントの数が増えています。これらのコンポーネント自体は、Facebookの消費者向け製品よりもはるかに大きな表面積を持っています。 したがって、サードパーティパッケージでも段階的に移行するための戦略が必要になります。

他の多くの企業とは異なり、コードベース全体で同じバージョンのReactを使用しています。 そのため、独自の課題もあります（たとえば、一部の製品のアップグレードを「待つ」ことはできません）。 これは確かに、優れた移行戦略を立て、ストレステストとして機能するように私たちにさらに圧力をかけるでしょう。

多くのオープンソースライブラリを使用している他の人々にとって、Proptypesを多くのライブラリから取得するのを待ってフラストレーションを感じるのは本当に大変な労力を要しました（そして私は大規模なreactコードベースをアップグレードした実際の経験から話します）。 限られたリソースで安定したビジネスを構築したい人には、速く動いて物事を壊すことは当てはまらないかもしれません。

気になる方のために、私たちはまだ次のようなコードを持っています

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」などをグーグルで検索するときに導入される痛みangular2+のように

それ以外はすべての変更を歓迎します!!!

@gaearon

あなたが言った

「一部の古いブラウザとの互換性を落とす必要があるかもしれません」

それは私が問題を抱えていたドロップ互換性パーツであり、次のポリフィルパーツではありませんでした。 暗黒時代に戻るのが心配でした。

プロセスについて。 この種の「問題」は、RFCプロセスが設計された目的ではありませんか？

それは私が問題を抱えていたドロップ互換性パーツであり、次のポリフィルパーツではありませんでした。 暗黒時代に戻るのが心配でした。

私は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要素の小道具がReactによって設定されているかどうか混乱しましたプロパティまたは属性。

これは、イベントリスナーがアタッチされている要素を指すevent.currentTargetでどのように機能しますか？ネイティブの場合は常にドキュメントを意味します-またはReactがそれに切り替わったらReactルートを意味しますか？

まだわかりません。 :-)何ができるか見ていきます。 これらのいくつかがうまくいかないか、異なって出てくる可能性は十分にあります。 この計画は、私たちが調査する予定の事柄の大まかな概要と、それらの統一ビジョンにすぎません。

DOMで何が起こるかに影響を与える可能性があるのに、なぜこれが実装の詳細なのですか？ それがclass/classNameのような属性（およびその逆）に何らかの形で反映されているプロパティのみを参照している場合を除きます。

それらの大部分については、どちらを使用するかをユーザーの観点から観察できる違いはありません。 私はそれらのほとんどが反映されていると思います（多分私は間違っていますが）。

私はAngularのバックグラウンドを持っており、Reactを使い始めたとき、それが私にとって最大の落とし穴です-Angularでは、属性、プロパティ、イベントハンドラーの分離は構文から直接明らかであり、DOM要素の小道具がReactによってプロパティとして設定されているかどうか混乱しましたまたは属性。

私はあなたの視点に感謝します。 ただし、実際には、この違いはほとんどのDOM要素とは無関係であることが多く、使用する要素の詳細を学習し、常にそれについて考える必要があることは、実際には日常の製品開発にとって価値があることは議論の余地があります。 人々が彼らを混乱させる程度は、それが実際には彼らにそれほど関連していないという事実を物語っていると思います。

（カスタム要素など、より関連性が高くなる場合があります。しかし、それでも、どちらを使用するかを選択する必要があるため、両方を等しくサポートすることは同じように混乱します。これは他の場所で議論されているので、ジャンプは避けたいと思います。この議論に再び参加します— @robdodsonのような人々からの提案があり、それらを調査します。）

@ Daniel15
言及されたポリシー（他のどこにも言及されていないと思います）がなければ、追加のオブジェクトラッパーはそれを決して安全にしません。
ユーザーはdangerouslySetInnerHTMLを介して危険な使用法について十分に警告されていると思います。 これは、ユーザーがドキュメントを確認し、影響を考慮して決定を下すことを余儀なくされた時点です。
（おそらくサニタイズされていない）文字列をオブジェクト/関数にラップする必要があるからといって、ラップされた値を再考したりサニタイズしたりする必要はありません。
それがそのように機能する場合、おそらく{ __html }は十分に複雑ではなく、 [{ _html: { __html }]はそれをさらに安全にします-安全にするために何かが危険であると何度も述べなければなりません？

あなたが提供した洞察で私はその理由を理解しましたが、「 { __html }はサニタイズされたhtmlを表す」ルールについての手がかりがないため、現在Facebook以外の人には当てはまらないと思います。
私はいつもそれがAPIのもう一つの障害だと思っていました。 時間を割いてそれに光を当ててくれてありがとう、今はもっと理にかなっています。

それは、それをより複雑にするだけでなく、サニタイズされていないデータが誤って使用されるのを防ぐことでもあります。

私は、反応がコミュニティによってとても意見されている方法が大好きです。 皆さんがそれをすべて聞いて、それを最大限に活用することを称賛します。

ここに来ている、または最後のバージョンでReactに来た変更が「壊れる」と誰もが考える方法が大好きです。 それらの人々は明らかにAngular2>3>4回を経験していませんでした。

私は変化が大好きです。 個人的にはclassNameを気にせず、 class $を破壊するのは面倒になる可能性があります。 しかし、私はあなたたちが何を思い付くのか見てみたいです。

この議論をトピックについて続けていただきたいと思います。 危険なHTMLを汚染することが役立つかどうかは興味深いですが、問題とは関係ありません。

Reactが大好きです

これは、新しい開発者がより歓迎されていると感じるのに役立つ絶好のチャンスです。 私はこれが起こっていることを非常にうれしく思います。

人々にクラスを使用させるだけでは、破壊と移行コストが機能しないことを除いて、悪影響はありません。

@gaearon 2cでスローしますが、これら2つのネガティブは、現在のネガティブと同じかそれよりも大きいように見えます（class => classNameを学習するための一時的な小さなコストと、破​​壊を回避すること+エコシステムレベルの移行コスト）。

React：heart：

上記の@natewをエコーし​​ます：

@gaearon 2cでスローしますが、これら2つのネガティブは、現在のネガティブと同じかそれよりも大きいように見えます（class => classNameを学習するための一時的な小さなコストと、破​​壊を回避すること+エコシステムレベルの移行コスト）。

とにかく、 classNameからclassに変更する動機は何ですか？
私があなたのコメントを収集できる限り、2つの議論に要約されます（私が間違っている場合は私を訂正してください）：

ほとんどの人が期待するものに概念的に近い

わかりましたが、 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を分解しても、タイピングがはるかに多くなります。 したがって、入力する文字数を12回減らして4文字減らしますが、 classを説明するたびに50文字追加しますか？ これはばかげています。

私が見逃したこの変更の別の説得力のある理由はありますか？
動機は、DOMの属性/プロパティへの準拠に関するある種の懸念ですか？
それは私にはあまりにも学術的な議論のように思えます。 ほとんどの人はこれらの実装の詳細をあまり認識しておらず、そうする必要はないと思います。

今日リリースされた場合、ReactはclassNameに変更する代わりにclassを許可するということですか？
それは関係ないと思います。
Reactは今日はオープンソースではなく、1年後にオープンソースになるとしたら、その時点で別の一連の決定が行われる可能性があります。
時々、すべてのしわを取り除くことを試みるよりも一貫性に固執する方が良いです。

そして、Reactが最初からクラスを使用していたとしたら、クラスを破棄してclassNameに再割り当てすることに慣れていたでしょうが、クラスをclassNameに変更するためのPRを持った人は誰でも、救世主と呼ばれます。

最後に、私は自分自身がこれについてそれほど苦労することを期待していなかったと言いたいので、失礼、侮辱、または非難として何かが出くわした場合はお詫び申し上げます。 Reactで行ったすべての作業と、Twitterにドロップしたすべての知識に感謝します。インタビューで与えたいくつかの回答を守るために、あなたのツイートを使用しました。

dan.churchに気が変わってくださいますように。

reactを継続的にアップグレードできることをとても嬉しく思います。reactを使用する開発者として、vueに追い抜かれることを望んでいません。 しかし、className->classのプロセスは苦痛でなければなりません。

コピー＆ペーストのためにclassName -> classの名前を変更することに反対しているわけではありませんが、現時点では明確な動機はありません。 classNameはDOMに存在しますが、 htmlForのようにどこからともなく出てくる予約済みの小道具名があります。 名前の変更に関しては、これらを優先する必要があると思います。おそらく、テストとしても役立つ変更の普及率は低くなります。

@sonhanguyen htmlForは、公式のWeb API名でもあります： https ：//developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

@ allan2coderは、配列でラップする代わりに、 <React.Fragment>または<>でラップします。

@ allan2coderまた、このスレッドをトピックに留めておきましょう。必要に応じて、別の問題を提出して質問することができます。

patch-packageに注目したいと思います。これは、依存関係にパッチを適用するのをかなり簡単にするパッケージです（たとえば、サポートされていないReact APIの使用を停止させるため）。 確かに、これはライブラリコードよりもアプリケーションコードの方が便利ですが、 @philipwhiukの懸念事項のいくつかに対処するのに役立つはずです。

私は楽しみにしてい。

• onChangeからonInputに移行し、制御されていないコンポーネントをポリフィルしないでください。

上記の言葉について、onChangeイベントはネイティブイベントの近くで使用されるのでしょうか、それとも将来使用されないのでしょうか。

@MuYunyun

言い回しに基づいて、彼らはonChangeの現在の動作を維持することを計画していません。 それはあまり意味がありません。 他の最新のライブラリのように反応することは、ブラウザの互換性レイヤーではなく、そうであるべきでもありません。

現在のonChangeは、onput+他のいくつかのケースをエミュレートします。 変更イベントがすでにDOMに存在し、同じセマンティクスを持たないことを考えると、まったく意味がありません： https ://developer.mozilla.org/en-US/docs/Web/Events/change

@jxub

少しオフトップですが、HTML属性をマップするための非常に多くの些細な変更でReactへの移行を容易にするためにhtml / css / svg-> jsxトランスフォーマーを作成するアイデアを誰も（私が知る限り）持っていなかったのはちょっと悲しいです小道具に反応します。 非常に多くの工数が、主に検索と置換を実行するために浪費されています:(

他のエディターについてはわかりませんが、HTMLコードをJSに貼り付けると、IntelliJ IDEA（およびWebStorm、PhpStormなど）がこの変換を行います。

少しオフトップですが、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は知らない人に特定のコンポーネントをアウトソーシングするときに使用するのは非常に一般的です。

したがって、これは人々が実際に使用する便利なツールであるというフィードバックを提供するだけです。 他のコンバーターもオンラインにあります。

このアプローチの問題は、それが一方向のみであるということです（_to_reactにのみ移行します）。 ただし、その問題はReactにとって特別なことではありません。

それが物事をはるかに簡単にすることを願っています...

このアプローチの問題は、それが一方向のみであるということです（反応するために移行するだけです）。 ただし、その問題はReactにとって特別なことではありません。

なんで？ 逆の場合はさらに簡単になるはずです— ReactDOMServer.renderToStringを実行するだけです。

リリースを辛抱強く待っています

@gaearon

なんで？ 逆の場合はさらに簡単になります—ReactDOMServer.renderToStringを実行するだけです。

さて、文脈上、議論される問題は次のとおりです。html/ cssを記述し、JSコードで作業するのに十分なJavaScriptを知らない人が、コンポーネントのマークアップ/スタイル/レイアウトで作業できるようにしたいと思います。

これを今すぐ行う1つの方法は、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スタックに精通している請負業者とのみ連携してください。 スタイル付きコンポーネントを学ぶ人を見つけるのははるかに困難です
• ノード（npm）、スタック（React、webpackなど）、およびノー​​ドを実行するために必要なその他すべてのものを、UIユーザーの各コンピューターでプロジェクトして最新の状態に保ちます。
• 基本的なプログラミングとJavaScriptを教え、devtoolsやコンソールエラーなどの操作方法を学びます。
• React、その構文、 className 、 keyの意味などを教えてください。
• HTML / CSSを作成するのではなく、そのように仕事をしたいと思っている請負業者やフリーランサーとのみ協力してください。 これは通常、物事をより高価にします。

さて、上記のように、react-skeptchappのようなものは、UIの人々にとってこれをより親しみやすく、簡単にするための便利な方法ですが、それでも多くのことを学ぶ必要があります。

私はあなたがこれを尋ねている理由を完全に理解しています、そしてこれが一般的な問題であるかどうかはわかりません（私はそれがそうであると思います）。 とにかく、それがReactDOMのコアの将来の範囲内にあるとは思いません。

これはまったく話題から外れています:-)Twitterまたは他の場所でこの議論を続けましょう。

「ツールが使用されているのを見る動作は、ツールが推奨する動作です」
〜ゲイリー・バーンハート

Reactの使用方法は、ほとんどがReactのAPIの一部ではないため、多くの落とし穴が発生し、このような議論の結果、誰もが混乱してイライラします。 classなどの予約済みキーワードを使用しているのは、javascript、html、またはそれ自体が原因で悪いですか？

16.3で行われた変更に戻ると（正しく覚えていれば）、vdomによってレンダリングされるネイティブhtml要素に渡される属性を受け入れることでライブラリの動作が異なるようになりました。コードベースのほとんどがバグに悩まされていたことをはっきりと覚えています。この明らかに悪いパターンを実装した動作の

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

だから私は、ダンがこのひどいコードをすべてのコードベースに広げ続けることを提案していることに非常に失望していると言わざるを得ません。

まず第一に、 propsの内容に保証はありませんが、最初は、間違った小道具を渡した場合、ネイティブhtml要素はほとんどの場合それらに期待されることを実行しませんが、同時に親の小道具を子のコンポーネントに伝播するのは安全だと考えられていますが、実際にはこれはひどく怠惰です

<Child {...props} />

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

何をレンダリングしているのかさえわからない場合があり、この問題への対処はさらに難しくなります。 また、型システムを使用してこれらの種類のコンポーネントを型チェックすることは非常に困難です。これは、ほとんどのコンポーネントが、相互に共有する必要のある多数のランダムなインターフェイスを実装する必要があることを意味します。

これを修正するために反応するように書き直した場合、その背後にある設計者は、悪い決定を2倍にするのではなく、これらの悪いパターンがコードベースに与える害を理解することを期待します。

jsxはjavascriptの上に構築されていることを覚えておく必要があります。キーワードの使用において言語と意図的に競合する言い訳として、javascriptの「特異性」を使用することは、APIを修正するための悪い第一歩であり、戦争を始める代わりに提案します。あなたがそれから完全に離れるであろう言語に対して

@gaearon久しぶり！ :)（ps。tl; dr先に申し訳ありません）

とにかく、私は自分の冒険から学んだことについていくつかの洞察を与えたかっただけです。 私は自分の「最小限の」React派生物を作成しました。これは現在、パフォーマンス/機能が重要なアプリケーションに使用しています。 最初は楽しい副次的な実験でしたが、他の多くの利点を含め、最初のレンダリング/更新/削除の実際のケースでは、パフォーマンスが+ 300％以上向上しました。 これは、プールされたイベントハンドラーも使用しません。

IIRCの大部分は、すべてのReact-propsロジックをバイパスし、属性をsetAttributeに直接フィードし、スタイルをstyle.setPropertyに直接フィードし、リスナーをaddEventListenerに直接フィードするという私自身のライブラリからのものです。 したがって、基本的なDOM要素インターフェースは次のようになります `{属性：{}、スタイル：{}、リスナー：{}、クラス名：" "、...}、より冗長ですが、インターフェースは小さく、実装が簡単です。非常に高速です。 これはおそらくあなたにとって極端すぎるでしょうが、それは私に非常によく役立っています。

私もやってきたことは、CSSを完全に削除することです。すべてのスタイルはインラインです。 予想よりもはるかに高速で、多くの優れた実用的な利点があります。また、ブラウザーの初期CSS解析（驚くほど高価です）と、オーバーヘッドの大部分を取り戻すセレクターマッチングのコストを回避します。 複雑な階層でも（ツリーの剪定なしで）、電力不足のラップトップで安定した60FPSを簡単に達成できます。

そのほとんどはあなたにとってあまり役に立たないと思いますが、何か面白いことがあるかもしれません。 とにかく、HTML + Reactに関する私の主な不満は、ReactユーザーコンポーネントがCSSに頼らずに、レイアウト/配置（そしておそらくある程度はイベントも）のためのインターフェイスを公開しないことです。 簡単に言うと、ButtonComponentを作成して使用すると、デフォルトでは、それなしでは配置したり、レイアウトに統合したりすることはできません。 その中に目的専用ロジックを実装し、配置可能なダミー要素でラップするか、ButtonComponentルート要素に使用されるスタイルにマージされるstyle-propを公開します。 それらのどれも完璧ではなく、スタイルをそのままマージすることは、あなたがすべきではないスタイルをそこに入れるのは簡単なので危険です。 基本的に、問題は、コンポーネントの境界で、使用可能なプロパティのサブセットがパブリック（配置/レイアウト）および一部の内部（ビジュアルスタイリング）である必要があることです。

私が行うもう1つのことは、コンポーネントとコンテンツ/子の分離です。 たとえば、DOMコンポーネントは子のリストを取得せず、代わりにコンテンツインスタンスを受け入れます。 コンテンツインスタンスは、調整ロジックと子のレンダリングを実装します。つまり、さまざまな目的に応じてさまざまな実装を行うことができます。 最も明白なユースケースは次のとおりです。 主に静的階層と動的に生成された子。 したがって、大部分を構成する静的階層は、より高速で単純なロジックを使用して実装できますが、動的に生成された子には構成可能な戦略がある場合があります。 また、不必要な間接参照なしにフレックスボックスレイアウトなどをインテリジェントに管理するために使用できる「コンテンツコンポーネント」を持つ可能性も開かれます。

これに関連して、Reactが間違っていると思うのは子供ですが、具体的な結論や解決策にはまだ到達していません。 しかし、Reactには根本的な問題があると強く信じています。つまり、2つのポイント間のすべての要素を再レンダリングせずに、ルートから階層内の任意のポイントに小道具をバブルすることはできず、効果的に剪定することも問題になることがよくあります。 パフォーマンスはほとんど「十分に良い」ものであり、Reactでこれを管理する複雑さが増しても、解決する価値がない場合があります。 しかし、これまでの私の実験では、ごく少量の些細なコードで完全なルート更新コストをほんの一部に減らすことができましたが、私の直感では、Reactの哲学やその単純な子モデルとはあまり互換性がありません。

ほとんど間違いなくあなたには向いていませんが、私のライブラリの大きな特徴は、基本的に、一般的な目的のために最小限の「基本DOM要素」しか提供しないことです。 特定の要件/状況で大規模なプロジェクトを非常に安価に開発している場合、「ハッキング」に頼ることなく、たとえば非常に頻繁に触れている場合など、独自の低レベルの特定の動作を簡単に拡張/置換および実装できるという考え方指向、特別なスタイル処理などを行いたい。これは、異なるバージョンに互換性があり、ABIが同じである限り、並べて実行できることも意味します（変更は非常にまれで、修正が非常に簡単です。 ）。 これはまた、すべてを網羅し、すべての人の問題を解決しようとする必要なしに、DOM要素インターフェースでかなり意見を述べることができることを意味します。

とにかく、おそらくほとんどがとりとめのないものであり、私はおそらくほとんどの概念をうまく伝えていませんが、反対の方向に進んだ誰かからの興味深い情報があるかもしれません。 あなたが「シンプルさ」をターゲットにしているという理由だけで、それのほとんどはおそらくあなたには関係ありませんが、誰が知っていますか:)

また、忘れる前に、私のobjectKeyValueReconcile関数に興味があるかもしれません。特に、Reactのようなシナリオの前/次の小道具を比較するために非常に高速になるように最適化されています。 それは私にとって非常に重要な実際のパフォーマンスの向上に責任があります。

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

私は「クラス」のアイデアを捨てます。 JSXは最終的には死にます。

非要素ベースのDOM/ウィンドウイベントのサポートをReactDOMに追加することについてどう思いますか？ 合成イベントが削除される可能性があるので、何らかの形のイベント収集/更新/バッチ処理がまだあると思います。 キー押下、サイズ変更、およびウィンドウスクロールイベントは頭に浮かぶ一般的なシナリオですが、 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モデルを期待しているということです。 このプロップの圧倒的な主な目的は、実際にはcssコードとリンクすることです。では、html / cssユーザーが期待するようにクラスと呼んでみませんか？

設計システムコード以外のIMO、実際には慣用的なReact開発では、通常、classNameまたはclassをあまり使用しません。 cssのクラスを使用する必要がある場合、ほとんどの場合、いくつかの小さなUIコンポーネントに分離されています。 アプリケーション層で使用されるほとんどすべてのものは、より高いレベルです（たとえば、 <Columns verticalAlign="center">または<BodyText />など）。

ですから、名前をclassNameからclassに変更すると、とにかく小道具を使用する種類の人々にとって簡単になるのではないかと思います（React開発に参加しやすく、コンテキストを切り替え、怒らないようにするのが簡単です）。 、など）、名前を変更してみませんか？

バンドルサイズを小さくしてください。

これは大きくて最新のアップデートなので、Reactのライフサイクルの命名も修正できるかもしれません！

つまりshouldComponentUpdate => shouldUpdateなどです。この命名はばかげたことを超えています。

@AlexGalays

これは大きくて最新のアップデートなので、Reactのライフサイクルの命名も修正できるかもしれません！

つまり、shouldComponentUpdate=>shouldUpdateなどです。この命名はばかげたことを超えています。

ライフサイクルフックの名前が長いほど、検索時にあいまいさが少なくなります。 短い名前は一般的すぎて、それらが配置されているコンテキストに依存するため、大きなコードベースの他の何かと偶然に一致する可能性があります（誤検知の一致）。

ライフサイクルメソッドはReactコアの一部であり、この問題は単にreact-domに関するものです。

@ljharb
おっと、確かに！

@sompylasar
申し訳ありませんが、それは単に正当な理由ではありません（しゃれを意図した、reasonReactはメソッド名を修正しました:)）。 すべてのモジュールにパッケージ名のプレフィックスを付けるわけではなく、問題はありません。 とにかく、react-coreはこの問題の範囲外なので、これについて話すのをやめます。

これらの変更を見てみたいです。
カスタム要素の相互運用を念頭に置いて実装されることを願っています。

いくつかの議論をフォーラム（https://discuss.reactjs.org）の別々のスレッドに移す価値があるのだろうか？ GitHubの問題はフォーラムの投稿のようにスレッド化されていないため、同じ問題で複数の異なることを議論するのは困難です。

className -> classの変更は私には興味深いようです😺

ウォッチ、2019Reactプロジェクト

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

私はこれが確かに来るのを見ます。

HTMLをコピーして貼り付け、 classNameを変更する必要がないのが大好きですが、同時にclassの予約キーワードがもたらす可能性のある問題があります。

この時点で、（個人的な好みではなく）エンジニアリングに関する強い懸念がない限り、 classNameを使い続けることをお勧めします。

しかし、それは私の実際的な意見です。

class識別子を破棄できないという追加の摩擦は理解していますが、このスレッドでは、クラス名を小道具として受け取る必要がある回数を過大評価している人が多すぎるように感じます。

classNameをReactコンポーネント（DOM要素だけでなく）に渡すということは、新しい抽象化を提供せずに非常に小さなビルディングブロックを作成するか、そのコンポーネントが実装の詳細の一部を公開することを意味します。 最初のケース（たとえば、 <Button />コンポーネント）では、 @ gaearonの例に従い、小道具の「残り」をDOM要素にも転送することをお勧めします。 2番目のケースでは、追加の摩擦により、そのことを避け、より良い解決策を考え出すことを余儀なくされる可能性があります。

私の謙虚な経験から、 classNameを受け取るコンポーネントを作成したことを思い出せないほど、HTMLをJSXにコピーアンドペーストする（そしてclassをclassNameに置き換える）必要がありました。

すべての小道具をHTMLに拡散することは、アンチパターンです。 将来誰かがHTML属性に一致する追加の小道具を含めると、予期せず動作が変更されます。 IEが新しい属性を追加すると、あなたはうんざりします。

@philipwhiuk使用しない小道具だけを広げれば、動作の問題は発生しません。

@ j-f1

使用しない小道具だけを広げれば、動作の問題は発生しません。

あまり。 コンポーネントAPIに新しいオプションを追加すると、このオプションは基になるDOMノードに渡されなくなります。 誰かが要素に設定されているその正確な属性に依存している可能性があり、それからあなたはその人を壊します。 未使用のすべての小道具を下にあるものに分散させることは、コンポーネントAPIへの追加が重大な変更であることを意味します。

ところで、私はランダムな例を使用しました。ここでは、 classの値を分解しますが、その詳細を切り落とさないでください。

多くの人（はい、そうです）は、余分なテキストの入力を避ける以外の理由以外にドット表記を使用する代わりに、 propsとstateからほぼすべての値を分解します。

だから私は状況に重点を置いていますが、横向きになって小道具を広めることや、それについて話すことができる別のサイドトピックに焦点を当てないでください。

もう少し実用的な場合は、個人的な好みではなく技術的な意味について話しますが、 classNameの技術的な意味について何も言っている人は誰もいません。

あなたが注意を払う必要があるもう一つのことは、あなたがコア貢献者に個人的な好みの問題に焦点を合わせさせているということです（私があなたにそれを実際的に考えて欲しいという理由だけで私が間違っていることを証明してください）

彼らの時間、労力、および（会社からの）お金は限られているので、コミュニティが私たちの注意を集中するためのより良いものがあることを理解し、コアチームの誰かが私たちがそれを使用することを好むものに1時間を費やす場合Reactの次の大きな点は、そのような変更のためのリファクタリングコードがないことです。

しかし、繰り返しになりますが、私の実際的な意見です。

ポリフィルと言えば、reactはユーザーが「良い」ポリフィルを指定したかどうかを検出しようとすべきではないと思います。
（例：コードのhasBadMapPolyfill ）
Reactは、プログラミングプロジェクトで発生する可能性のあるすべてのランダムなミスに対して責任を負わないようにする必要があります。

@AlexGalays Reactは、正しいセマンティクスを持つMap実装の使用に依存しています。 ユーザーが非準拠のポリフィルを使用している場合、アプリが予期しない混乱を招く方法で破損する可能性があるため、その場合は事前に警告しておくと便利です。

これは開発ビルドでも行われるため、本番環境ではオーバーヘッドは発生しません。

私はこのReactFireが大好きです。これは、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>
 }
}

イベントシステムを簡素化するもう1つの利点（すべてのフレームワークのようにプールせずに生のDOMイベントに戻ることができますか？:)）は、静的に入力することも簡単になることです。

素晴らしい計画のようです！ IE 11をサポートすることは本当に素晴らしいことです（たとえそれが私たち自身のポリフィルを出荷することを意味するとしても、それは完全に問題ありません）。 政府機関のクライアントと協力している人として、IE11の使用をいつ停止するかは完全に不明です:(

@MatthewHerbst同じボート、私たちのクライアントはIE 11を使用しており、十分なトラフィックがあります😢

これはすべてとてもエキサイティングだと言ってチャイムを鳴らしたかっただけです。 私が心配して読んだことの1つは次のとおりです。

既存のブラウザの違いの一部をスムーズにしようとしない可能性があります

今のところ、ReactのイベントシステムがReactがサポートするすべてのブラウザーで「正常に機能」することを知っているのが大好きです。 この変更は、クロスブラウザの問題を説明することがアプリの責任になることを意味するのではないかと思います。 これにより、追跡が難しいバグが多数発生する可能性があります。 ...少なくとも私のアプリではそうでしょう。 :)

とにかく、いつものように素晴らしい図書館に感謝します。

@kentcdoddsは、私が戦略を読んでいた可能性のあるアイデアとしてJSX 2.0統合について言及していましたが、それに関連していると思われるものは何も見られませんでした。 それが空中に浮かんでいるのか、それとも将来のために延期されるのか、疑問に思いました。

IEを死なせてください！ 完全に古いブラウザはサポートしないでください。 制限のある会社であっても、最新のブラウザに切り替えない理由はありません。 あなたとウェブがそれをサポートしなくなるまで、あなたはあなたの統計にそのIE11を見るでしょう。

@hbroerレガシーソフトウェア？

@hbroerサイトがまだ機能しているため、古いブラウザにとどまる人は誰もいません。選択の余地がないか、更新方法がわからないためにそうしています。 これらのユーザーのためにサイトを壊すことは非常に敵対的であり、更新されたブラウザーではなく、何も残しません。

• 「更新方法がわからない」-問題ではありませんが、ブラウザのリストと、Microsoftホットラインのヘルプテキストと電話番号を使用して「新しいブラウザをインストールしてください」というメッセージを入力できます^^
• 「選択の余地はない」-そうですが、組織は環境を更新する必要があります。 ツールが機能しない場合は、機能します。

私は過去のコーディングが嫌いで、新しいテクノロジーのメリットを利用できません。なぜなら、コーダーの90％は、前世紀に住んでいた下位15％の消費者のくだらないブラウザーをまだサポートしているからです。 ^^今後10年間、この「このInternet Explorer 6オタクとは何ですか。15％をサポートする必要があります」ということはしたくありません。

ところで、M $の継ぎ目は、Edge forWindows7および8とWebkitへの切り替えをもたらします。

@hbroerそれがユーザーに影響を与える場合、すべてが私たちの問題です。 他の人間に共感を持ってください。

（これとは別に、 M$はかなり若く、非常に古い90年代後半の参照であり、削除することをお勧めします。削除する場合は、これを脇に置いておくことができます）

なるほど、ここにたくさんのM$ファンボイズがあります。 ：DIは本当に人間を気にしますが、テクノロジーの進歩を妨げる組織や、何年にもわたってその古いがらくたをサポートしなければならないことを意味するコーダーは気にしません。 ライブラリを「古いがらくた互換」にする追加パッケージに問題はありません。 ただし、2019年のライブラリは、<= 2013技術ではなく、>=2019技術を念頭に置いてコーディングする必要があります。 それをサポートしなければならないのは十分に悪いことです（ああ、これをもう少し別の方法でやらせてください）サファリと（古い）エッジがらくた。

micdrop

@hbroerは、実際、古代のandroidブラウザー、および古代のsafariは、どのMicrosoftブラウザーよりも問題です。 それは「ファンボイ」であるということではなく、プロであるということであり、「M$」という用語を使用することはそうではありません。

いいえ、古い技術をサポートすることは決して「悪い」ことではありません。それは道徳的かつ倫理的なことです。 悪いのは、Netscape Navigator、IE 6、最新のChromeのいずれであっても、「Xで最適に動作する」Webサイトです。

なるほど、ここにたくさんのM$ファンボイズがあります。

@hbroerここに人身攻撃をしている人がいます。

ただし、2019年のライブラリは、<= 2013技術ではなく、>=2019技術を念頭に置いてコーディングする必要があります。

いいえ、すべきではありません。

1秒かかり、browserlistのデフォルトを調べた場合、驚かれることでしょう。 代わりに、人身攻撃や学校の食堂レベルの侮辱に訴えます。

十分な数のユーザーを獲得すると、IE11はあなたのWebサイトにアクセスするかなりの数の人々になります。 以前の仕事では、月に100万人近くがIE11からWebサイトにアクセスしていました。

古いがらくたをサポートしたい場合は、ポリフィルを追加します。 将来と現在のためにコーディングしない理由はありません。 古い技術をサポートすると、Webアプリは必要以上に太くなり、遅くなります。

追伸私は皮肉を読むことができず、スマイリーを気にしない人を見ます^^

@hbroer IE11が存在することを示しているので、そのためのコーディングが期待されています。

そして、もう一度。 https://browserl.istでデフォルト値を参照してください。

追伸私は皮肉を読むことができず、スマイリーを気にしない人を見ます^^

ええ、違います。 これは、トロルや遊び場のいじめっ子が採用する一般的な戦術です。 「なに？！私はあなたを侮辱しませんでした！それはただの冗談でした！」。

「インターネットを利用する人」でさえフィルタリングされた地球上の人々の0.20％は640万人の人間です。 パーセンテージはまったく関係ありません。 人間のためのコード; 過去と未来、そしてバンドルサイズは関係ありません。

ブラウザの互換性と同じように、人間のバンドルサイズをコーディングする場合は、確かに重要です。 ユーザーは物事が機能することを期待するだけでなく、ロードも高速である必要があります。

今2019年に、私は新しいプロジェクトcssグリッド（IE11での実験的なサポートのみ）に使用し、ES6にトランスパイルし、その古いブラウザーにポリフィルを配信したくありません。 IE11ユーザーは、次のメッセージを受け取るだけです。ブラウザを更新するか、別の方法を使用してください。

Javaスクリプトを使いたくない人がいます。 あなたはそれらを気にしますか？ あなたは統計にその人を見ていません。 そして、そのツールをブロックしている他の多くの人々のように、私も統計に参加していません。

私は時代遅れではないすべてのブラウザに目を向けています。 私は、Windows 7（2020年1月の終わりをサポート）のために、IE11のがらくたよりもユーザーが少ないエッジをサポートし、現代の人々は最新のブラウザーを使用しています。 ^^

ポリフィルや互換性パッケージのようなものの使用を止める人は誰もいません。 ただし、コアは最新のものである必要があり、古いM$技術ブラウザの1つだけが原因で遅れをとってはなりません。

私が多くのjavascriptフレームワークに欠けているのはLTSです。 それが私たちが話すことができることです。 現在の機能を備えた最新のページを作成する場合は、最新の技術フレームワークを使用すると便利です。 また、最大限の安定性と互換性を必要とするb2b用のWebアプリを構築している場合は、LTSバージョンを使用できます。 またはノックアウトを使用します。 そうすれば、IE6で更新されていないWindowsXPをまだ使用している数百トンの人々をサポートできます^^

互換性は元の投稿の「トレードオフ」に明確に記載されているため、古いブラウザを完全にサポートすることはすでに二次的な焦点となっています。

それらをサポートする必要がある場合は、より多くのポリフィルと統合が必要になりますが、そうすることはあなたの選択です。 また、ブラウザターゲットごとに複数のバンドルを作成し、訪問者ごとに可能な限り最小の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の一部である他のアイテムの作業を一時的に一時停止し、最初にイベントシステムのみに焦点を当てることにしました。 そのプロジェクトはReactFlare（https://github.com/facebook/react/issues/15257）として知られるようになりました。 それ自体は十分に挑戦的であり、このリストの他の項目に影響を与えるため、最初に単独で焦点を当てます。

React Flareの目標は、マウスとタッチを使用して、デスクトップとモバイルで快適に使用でき、アクセス可能なUIを簡単に構築できるようにすることです。 Press、Hover、Focusなどのインタラクションを管理するための宣言型APIが含まれています。 現在のReactイベントシステムとは異なり、Flareデザインは、使用しないイベントのバンドルを膨らませることはありません。また、マウスイベントとタッチイベントを処理するUIライブラリのコード量を削減できるはずです。

React Flareはまだ実験段階ですが、全体的な方向性にはかなり自信があり、最終的にはオープンソースで正式に利用できるようにする予定です。 （現時点では、マスターから手動でビルドした場合にのみ機能します。積極的に取り組んでいるため、semverの保証はありません。）Fireと同様に、「Flare」は単なるコードネームです。出荷時には、次のようになります。適切な命名、ドキュメントなど。たぶんreact/eventsまたはこのようなもの。 最終的には、ReactNativeでも同等のイベントを提供したいと考えています。

React Flareの最初の実装が終了したら、React Fireリストに戻り、そこから学んだことを使用して他のすべてのポイントを再評価します。 Flareが「より豊富な」イベントのセットを引き継ぐ場合でも、React DOMでの「基本的な」イベント処理を簡素化し、多数のポリフィルを削除できる可能性があります。 これまでの議論に感謝します。これがお役に立てば幸いです。

すごい仕事！ したがって、イベントシステムは、マウスイベントとタッチイベントのバランスを取るために引き続き必要ですが、軽量でReactから独立しています。

「ReactFlare」はデフォルトのReactパッケージの一部として提供されますか、それとも同梱されるAPIの量を考慮して追加のインストールが必要ですか？

未使用のコードがバンドルされないようにしたいと思います。 したがって、現在の意図は、APIごとにオプトインすることです。 たぶん、単一のパッケージに別々のエントリポイントがあります。

このマウスとタッチイベントシステムはPointerEventを活用しますか？ 前回の更新ではこのWeb標準についての言及は見られなかったので、注意を喚起したかっただけです。

ポインターイベントは、ポインティングデバイスに対して発生するDOMイベントです。 これらは、マウス、ペン/スタイラス、タッチ（1本以上の指など）などのポインティング入力デバイスを処理する単一のDOMイベントモデルを作成するように設計されています。 ポインタは、特定の画面座標のセットをターゲットにできるハードウェアに依存しないデバイスです。 ポインターの単一のイベントモデルを使用すると、Webサイトとアプリケーションの作成を簡素化し、ユーザーのハードウェアに関係なく優れたユーザーエクスペリエンスを提供できます。

そして、ここに現在のブラウザの互換性への直接リンクがあります。

@jonathantnealはい、新しいシステムはポインターイベントを多用します。ポインターイベントがサポートされていない場合は、マウス/タッチイベントにフォールバックします。

この問題ではhttps://github.com/facebook/react/issues/11347が取り上げられていないのではないかと心配しています。 フランクに反応する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フレアが出たので（SCNR）、更新された計画（ 2019年6月5日更新に関して）はありますか？

また、 @ trusktrと同様に、ここで＃11347のアドレスを取得したいと思います。

ポリフィルを別のバンドル、特に主要な常緑ブラウザに関係のないバンドルに分割することができます。

ねえ、それは久しぶりで、私たちはこれらのことのいくつかをオンとオフで試しました。

それぞれについて最新情報をお伝えします。

• value属性（https://github.com/facebook/react/issues/11896）への入力値の反映を停止します。 これは元々、 https：//github.com/facebook/react/pull/6406を介してReact15.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を「予約」して、このリストの次の項目に集中できるように、可能な限り重大な変更を最小限に抑えることにしました。 したがって、この変更はReact18まで待機します。

• ドキュメントではなくReactルートにイベントを添付します（https://github.com/facebook/react/issues/2043）。 Reactアプリを大規模なシステムに埋め込む場合、ドキュメントにイベントハンドラーをアタッチすることが問題になります。 Atomエディターは、これにぶつかった最初のケ​​ースの1つでした。 大きなWebサイトでも、最終的にはstopPropagationが非Reactコードと相互作用したり、Reactルート間で相互作用したりすることに関連する非常に複雑なエッジケースが発生します（https://github.com/facebook/react/issues/8693、https://github .com / facebook / react / pull / 8117、https：//github.com/facebook/react/issues/12518）。 また、更新中の実行時チェックを減らすことができるように、すべてのルートにイベントを熱心に添付する必要があります。

これはReact17で行っています。これは膨大な作業であることが判明しましたが、ありがたいことに終了しました。

• onChangeからonInputに移行し、制御されていないコンポーネントをポリフィルしないでください（https://github.com/facebook/react/issues/9657）。 詳細な計画については、リンクされた問題を参照してください。 ReactがDOMのinputイベントとして知られているものに異なるイベント名を使用することは混乱を招きました。 通常、このような大きな変更を大きなメリットなしに行うことは避けますが、この場合は、動作を変更して、制御された入力の変更などのエッジケースにのみ必要な複雑さを取り除きます。 したがって、これら2つの変更を一緒に実行し、それを機会として使用して、 onInputとonChangeを制御されていないコンポーネントに対してDOMイベントが実行するのとまったく同じように機能させることは理にかなっています。

これに戻る可能性がありますが、ここで解約する価値があるかどうかは不明です。 したがって、これはまだ未定です。

• イベントシステムを大幅に簡素化します（https://github.com/facebook/react/issues/4751）。 現在のイベントシステムは、2013年の最初の実装からほとんど変更されていません。これは、ReactDOMとReactNativeで再利用されるため、不必要に抽象的です。 それが提供するポリフィルの多くは、最近のブラウザーには不要であり、それらのいくつかは、解決するよりも多くの問題を引き起こします。 また、ReactDOMバンドルサイズのかなりの部分を占めています。 ここでは具体的な計画はありませんが、おそらくイベントシステムを完全にフォークし、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）。 これは数え切れないほど提案されています。 React 16ではすでにclassをDOMノードに渡すことを許可しています。これが引き起こす混乱は、保護しようとしている構文上の制限に値するものではありません。 この変更を単独で行うことはありませんが、上記の他のすべてと組み合わせることは理にかなっています。 コンポーネントエコシステムの処理が非常に困難になるため、警告なしで両方を許可することはできないことに注意してください。 各コンポーネントは両方を正しく処理することを学ぶ必要があり、それらが競合するリスクがあります。 多くのコンポーネントがclassNameを処理するため（たとえば、それに追加することによって）、エラーが発生しやすくなります。

これは提案の中で最も物議を醸した部分でした。 それ以来、関数コンポーネントの作成を促進するフックをリリースしました。 関数コンポーネントでは、通常、小道具にデストラクチャリングを使用することをお勧めしますが、構文エラーになるため、 { class, ... }と書くことはできません。 したがって、全体として、これが実際に実行するのに十分な人間工学的であるかどうかは明らかではありません。 将来、これを再検討するか、少なくともclassに警告を出さず、人々にやりたいことをさせようとするのはもっともらしいことだと思います。 しかし、今のところ、このアイデアを棚上げします。

こんにちは、素晴らしい記事です！
React-DOMの製品サイズを削減する計画がパイプラインにあるかどうかを知りたいだけですか？ モバイルアプリケーションの場合、ブラウザーが100KB以上のReact-DOM JSを解析してから他のモジュールを解析するため、依然としてオーバーヘッドが発生します。 次に、アプリ固有のJS。
コンテンツが豊富なページの場合、ブロッキングとTTIが大きくなります。

そのような変化をいつ見ることができるか、何か考えはありますか？

@ morevolk-latei測定では、100 KBのReactDOMの解析にどのくらいの時間が費やされていますか？